Re: Philosophical question...

[alex dinovitser]

Hi,
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. I'm all in favour of the "microkernel" approach (ala
QNX.com )so that a modular approach based on a minimal base is possible.
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.

==
------------------------------------------------------------------
Alex Dinovitser
PhD Student                            ph:  [phone]
Transport Systems Centre               fax: [phone]
City East Campus
University of South Australia   
Adelaide       5000
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Philosophical question...

[Matthias Wächter]

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