[ge-talk] Get login details while booting.

[Jonas Sundström]

"v r" <vreikine at lycos.com> wrote:
 ...
> Personally, I am not involved with kernel development but it 
> seems to me that if instead of a buffer for command line space
> the kernel would allocate a space for 640x480x16 framebuffer
> that would not be really "user interface as part of the kernel" 
> problem. It's not dramatically different from BeOS boot screen
> - graphic logo and 5 circles changing colors as boot process goes.
> It was waiting for user input as well - if you'd hit F1 at the right 
> moment it would run debug output to serial port. All it needs is a
> little bit more elaborated keyboard handler to hide the password. 
 ... 

I know you guys are trying to think "outside the box", but this is 
highly dependant on the inside.

The implementation of this idea is a lot more complicated than simply 
displaying a boot splash screen or setting up a graphics framebuffer. 
The kernel does all kinds of invasive hardware probing and configuring 
during bootup, disabling and enabling hardware interrupts back and 
forth, and to have keyboard input work at all during all this heavy 
lifting is most probably -not- trivial at all. 

There is a window of opportunity before booting the OS, during the 
initial boot where the PC BIOS is still in control of hardware 
interrupts. We're still in legacy 16-bit "real mode", and that's when 
input can be received by a early boot manager, using the services of 
the BIOS. BeOS's "Bootman" does this. I believe Bootman has to live in 
512 bytes of machine code, to fit the Master Boot Record which is one 
sector large, so you can't fit much more in there. 

As soon as the boot loader switches the CPU/system to 32-bit mode, the 
BIOS is waived goodbye, and with it any practical hope of accessing PS/
2 or USB devices in legacy mode (PS/2) until Haiku itself has 
initialized enough device drivers and started the essential system 
services.

(For the record, yes, it is possible to access the BIOS from 32-bit 
protected mode, but when the OS has taken over interrupt management, 
which is necessary, e.g., for the OS to receive keyboard button ups/
downs, I don't think the BIOS gets keyboard input any more. Anyway, 
it's most probably a *very* bad idea to switch back and forth between 
real and protected mode during the sensitive bootup process, just to 
poll for keyboard activity.)

Have you guys tried Haiku on real hardware recently? *Everything* is up 
before my PS/2 keyboard gets probed and reset to a working state. Your 
hardware may recognized earlier, but I assure you there's nothing odd 
about mine. Intel chipset, Microsoft devices.

It's not possible to have USB and Bluetooth devices work during the 
boot process before the OS has initialized device drivers and started 
system services, and there's no practical way to present a decent GUI 
until the system has finished booting the essential parts. It would be 
interesting to know how Windows XP's boot process works, but even so, 
it may not be a solution that works well with Haiku as its bootup 
process is implemented currently. IIRC, we ditch the BIOS early and 
never look back.

It may be possible to halt the boot process completely at bootman or in 
the next boot loader step (the volume boot record, most probably), and 
have that loader use the BIOS and receive the login credentials, and 
only then continue the boot process, but why? 
It's a very short wait. 

With the current generation of PC hardware, implementing this is just -
not- worth the work, possibly in horrible 16-bit real mode PC assembly, 
and redesigning the Haiku boot process. The current boot process is 
somewhat designed (with clean breaks between the boot stages?) to be 
portable to future hardware targets, such as the Apple PowerMacs, BIOS-
successor EFI PCs, the Playstation 3 or whatever. It's a bad thing to 
add more x86-ism to Haiku just to have it appear to boot slightly 
faster, if you at the same time make it harder to port to other 
hardware. This is important, and we're actually quite close to (or in) 
a hardware leap now, with the AMD64/EM64T, so portability is very much 
relevant.

Anyway, in the future, lets hope we can *soon* forget about passwords 
and use smart cards, wireless open-sesamy (and sudo?) buttons 
(bluetooth?), an entry key on a USB flash memory, or whatever. 
Passwords aren't user friendly in the least. Let's just get rid of them 
alltogether. People deserve better.

Sorry for being Mr Rant today. :P

/Jonas Sundström.