On Thu, 4 Feb 1999, alex dinovitser wrote:
I have been following this dicussion for a while, I think the capability to boot of a network (USB, etc) is definitely a good one, but as long as it is an optional module that the BIOS can work without.
Of course. OpenBIOS should not be a way of getting a remote boot BIOS for free, programmed by dozens of programmers in several months :-)
I'm all in favour of the "microkernel" approach (ala QNX.com )so that a modular approach based on a minimal base is possible.
Of course, OpenBIOS should leave the choice of being as leightweight as needed for everyone. But this implies only code _size_, not the structure. For things like remote boot being able to be used with strong encryption as the hard disk- or floppy- or CD-ROM-boot should, we need a well-known and to-be-defined structure for all the devices to interact at boot time. If one doesn't need authentication and boot progress verification at boot time (and I think there will be a lot of users like that, at least in the next 3 to 5 years), he will have the opportunity to disable this feature in the configuration. If he enables it, it has to fit into the whole structure, not just as an add-on, fitting to the rest of the code as bad as skin cancer on the face.
I think that both pro and con arguments are valid, and the forward from here is starting with some list of prorities, like starting with the pre-boot algorithm that reads the state of the Reset Switch to invoke boot, and optimising this algorithm to account for things like metastability in digital circuits. I feel we have a lot to do if this project is to progress.
Like I already said, of course, we need volunteers programming things like chip set setup code, code to use devices behind IDE bridges, SCSI controllers and network adapters, and we need them soon. But we also need a clique to discuss the main structure, the skeleton for the whole project. We need decisions where decisions _must_ be made, and we need specifications for topics where it is left to the programmer to implement. Say, we have to specify how to walk through a door, but we also have to specify how to setup new doors to meet additional needs and how to choose between different doors to walk through.
Of course, OSS and GNU and this discussion forum allows for flat democracy, but we should start building a skeleton with some fixed and some loose specifications for low level programmers to know how to do it. Building a skeleton implies to know what it should look like later when it's done. We don't need people just telling "no, that's not what I want", we need people telling exactly what they want, what's missing or what they intend to use it for _NOW_. Not in one year, not, "when it is finished". Now.
Winscheichwos, - Matthias