> and starts as the first rc.0 stuff.
I see; erase all the non-fatal errors and warnings and information that
come up before init starts. Good plan.
> With a hack in the bootsect.s stuff to
> save state and set VGA mode and set a hatch pattern (about 50-100 bytes in
> code size), this is all possible. It doesn't have to display a picture (if
> it does, I'd expect it to be after the file system is mounted, maybe use
> png as the delivery mechanism). I want no text unless Something Very Bad
> (tm) happens.
What can't text do? And what can graphics mode do better (not just
cuter)? The current boot, while not pretty, is at least as pretty as
booting DOS, yet many times more informative, often down to component
version numbers. And all of what you described could well be done from
/etc/rc and doesn't have much of a reason to belong in the kernel...esp.
if it fails.
> Saving the VGA state is a well known procedure. Setting up
> 640x480x16 colours is easy, and works even on 256 kb VGA cards. There was
> one person who said that you couldn't see what went wrong. Well this
> problem has been solved on the Mac for more than 12 years (a red cross is
> placed through the icon of the extension or control panel that failed).
That's who went wrong, not what. The difference is a few useful,
descriptive lines (or maybe a panic dump!) vs. one bit, red X or no
red X. Just because we can enter graphics mode, produce a hatch pattern,
and fling up icons (and paint some red) doesn't mean we should.
> Simple expect script could leverage this under free unixes. Even OS/2 boots
> graphically.
If someone wants to write something that watches the kernel output in
userland and renders that graphically, that's fine. But it doesn't need
to be in the kernel, let alone the main kernel distribution.
> * when Something Very Bad happens, I want something that is better than
> now. Say fsck fails. You're screwed now. There is no easy to enter single
> user mode from this angle.
Even the simplest rc scripts, from day 1, dropped you into single-user mode
if fsck failed, since the distributions that came with 0.94 or so at the very
least. Now, if mounting the root filesystem fails, you need a floppy
anyway, so the difference between an init=floppy option and a rescue
boot/root disk pair is minimal (and not kernel related). And "no easy way"
to enter single-user mode doesn't at all compel graphics.
> Say a driver module you've installed stalls the
> boot process. Where's the single user mode?
Why does unstalling the boot process require anything graphical at all?
Your arguments are so far completely orthogonal to graphics or graphics
mode, and some of them don't even belong in kernel space.
> Many people who don't do kernel
> hacking or driver development don't have boot disks around to do repairs.
> We need something that will help get the system stable at boot time without
> resorting to floppies.
Perhaps, but in that case your best second bet would be an intrd that can
stand on its own if mounting / fails...which amounts to making a rescue
boot and root disk, then stuffing them into your kernel image, so why
bother stuffing it into the kernel image?
If you do go with your graphical bootup project, though, choose a soothing
cloud pattern over an ugly hash pattern. After all, we've got to keep
up with the Gateses.
Keith