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