[LinuxBIOS] Specifications

[Peter Stuge]

On Wed, Jun 13, 2007 at 05:28:02AM +0000, Brendan Trotter wrote:
> I just think it'd be annoying for end-users if (for e.g.) the
> payload decided to use the 28800 8N1 for serial communication when
> LinuxBIOS is using 57600 8N1 because there was no way for the
> payload to determine how LinuxBIOS is currently configured.

It can just not set up the serial port but use it immediately and it
will keep the settings that LinuxBIOS used.

Granted, which one to choose must still be specified in the payload.


> As far as I can tell, Stefan's "You choose." either implies that
> it's my choice what LinuxBIOS developers do or that it's my choice
> how end-users configure LinuxBIOS. I doubt I've got that much
> influence with either group.

You would be surprised how receptive and tolerant this group of
people is. Ron even writes code the way I want if I nag him enough.
(Hi, Ron! :)

I think what Stefan wanted to say was that LinuxBIOS behavior is
rather configurable and the person building it gets to decide many of
the things you're asking about.


> I'll assume that whether or not ROMs are assigned physical
> addresses, whether or not device may be left in a power saving
> state, and whether or not MSI may still be setup is all "undefined"
> - not guaranteed either way.

I think this is belittling the effort in this project to initialize
hardware.


> > > There's a simple and easy way to find out if a monitor is
> > > attached or not, and it doesn't involve messing about with EDD
> > > - simply give the end-user the option of setting (or not
> > > setting) a value in the CMOS.

It depends. This is not workable unless there actually is an
end-user. It's also not workable unless said end-user is actually the
system administrator. LB was initially designed to explicitly not
have much user interaction and certainly not at boot time. A few
settings are available, but the idea is to always boot the OS
regardless.


> > This is already an option, to have vga you run the vga rom and
> > send output to the monitor. Otherwise, you keep serial output and
> > don't bother with the rom.
> 
> This is an option for end-users, but not something a payload can
> assume.

Watch out there. CMOS VGA/SERIAL is also an option for end-users, but
not something a (robust) payload will want to assume.


> > > My (limited) reverse engineering has already shown that there's
> > > CMOS entries for a serial port (possibly intended for setting
> > > up a serial cable to communicate with a terminal emulator?).
> >
> > Why reverse engineer? The source code is openly available ;)
> 
> There is little practical difference between reverse engineering in
> the traditional sense, and "reverse engineering" source code.

This depends a lot on the source code IMHO.


> In both cases it tells you nothing about what is guaranteed and
> what is coincedence (or what is incorrect behaviour), which values
> are valid for different fields, or what may or may not be
> implemented in future or past versions.

The code may not, but comments may, and discussion will.

I find that getting "into" open source projects is by far the best
way to learn how they think. Documenting the train of thought is IMHO
not worthwhile (although for new developers it would be nice) until
the code itself actually becomes rather high quality. It's better to
write code.

You are right that LB could have more and better documentation but
there is already a good amount available. There has not yet been much
demand for the kind of documentation you are asking for but perhaps
you can help us improve.

Meanwhile just talking to us will get you far.

(Please don't forget to read COPYING if you haven't already, though.)


//Peter