* Brendan Trotter btrotter@gmail.com [070613 07:28]:
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.
Often, the payloads have the choice to expect the serial port being initialized, so they don't change the speed. But I agree your approach makes sense.
One thing we are lacking though is a library or small set of functions that allows the (os less) payload to access the cmos and parse those parts of the lb table. all a payload ever parsed that i know of is the "memory" part of the memory tables
If LinuxBIOS told the payload "use the frambuffer, which is in ? * ? mode at ?" or "use the serial port at ? at ? baud and ? protocol", then the payload could seemlessly autodetect at run-time and continue using the same method for text output that LinuxBIOS used. Without this end-users would need to mess about with compile-time settings for the payload, and possibly recompile the payload if CMOS settings are changed after LinuxBIOS is installed.
Yes. We must export a lot more information in the LB table. I like this idea. And I think v3 will be a lot more like that.
I'm not sure googling for the information about the strings the LinuxBIOS project may or may not use in future for it's identifiers would help, unless (for e.g.) the "payload hand-off specification" explicitly states that the identifiers (if present) must be identical to those used by SMI/DMI, in which case I could google for SMI/DMI identifiers....
Nope, any similarities are coincidential. And not intended? ;-)
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.
When you build a LinuxBIOS image, you can decide whether this image will call PCI option ROMs or not. Of course the developers will try to set reasonable defaults. Of course the user might remove all plugin cards from his machine.. :-)
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.
No device will end up with ROMs assigned, as the PCI standard forbids that. No device will be left in a power saving state. No idea about MSI, I never did that on AMD hw
There is little practical difference between reverse engineering in the traditional sense, and "reverse engineering" source code.
You are no doubt coming from a "legacy grade environment" or "commercial grade source code quality". Since we are trying to get more people into the project, we try to make the source code as easily understandable as possible, and we work on improving it.
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.
"guaranteed" is a difficult word. You can always fork for a specific application and thus guarantee that the environment will not change.
We might break compatibility since hardware is living fast and we rather want to do a good job on supporting hardware well.
Since we are a heterogenous group, it is hard to forsee what may be implemented in the future (heck, no homogenous group can do that either, except the illuminati) It's mostly "requirement driven development".