On Thursday 24 January 2008, Patrick Georgi wrote:
... ports at 0x400) for crucial devices.
That's the term: "cruicial device", or "essential device".
This way a payload could have a console on COM1 and get its data via PPP or ZMODEM on COM2. With only a console setup, it wouldn't know about COM2, with only a serial ports table, it wouldn't know where to find the user...
IMHO this case is artificial. Zmodem can be muxed with the console, and with a second port or PPP, you'll need basic multitasking or at least a working interrupt subsystem.
The proposal is layered in two types of records:
The first type is an I/O-device record, like the serial port record I wrote. These can be extended with additional information as neccessary (and independent from other device types!), which might include IRQs or enumeration (in case we ever support more than one serial port in cb itself, for example).
I'm not sure I understand you correctly. I would think about LB_TAG_DEVICE, which, after the obligatory length, first has a type field , for e.g. 8250, IDE, AHCI and so on. The problem is that beyond serial ports, things quickly become hierarchical and thus complicate (bloat) the code.
These record are specified and designed on an as-needed basis, so we don't fall in the trap of over-engineering.
Maybe this already is over-engineered. I still see no valid case for serial.
Multiple devices are specified with one record (of the same type) per device, with some identifier (int) to tell them apart (added when we first use this strategy).
You'll probably stick all identical devices into an array.
By only adding data to the record's end, they're implicitely backward compatible,
NO. record types and version info have proven valuable countless times in the past, but maybe I'm over-engineering now. At least the record sub-type should impose limits on the length.
Payloads can figure out which information exists based on size as well, by ignoring any field that exceeds the size.
Payloads should check for device records with known sub-type.
The second type is a console type. It consists of tag and size (like every record), and an integer (enum) type that specifies the device type (eg. serial=0, vga=1, ...).
So we all agree we need something like that. Presumed we have abvove records, the sub-type and index would be sufficient, right.
Later, this record can be extended to also carry a device number (if there are multiple serial ports)
I thought this was your original motivation? So let's add an index right away, to prevent backward-compatibility problems later.
and maybe priorities or markers that consoles should be used in parallel (serial + vgatext). Multiple consoles would again be done by adding one record for each console.
Now you are definitely over-engineering. My proposal for alternate/auxiliary consoles was meant as _replacement_ for a full device list. If CB logs to VGA, but the payload only has a serial driver (or vice versa) things shouldn't stay totally in the dark. With all serial ports listed, the payload can arbitrarily pick one, if the CB console isn't on any of them and the log device will change anyway.
I'd like to go on with that, and will do so in a few days. Please don't wait until I have a patch ready for all that stuff, before telling me it's crap ;-)
There were only misunderstandings about the goal to be achieved.
Still I do not see a console use case for this split scheme. The only reason I'm still into this is: faster booting. Extending/splitting the info about the console in use into a config and a device part allows extensions for those devs that are slow to probe, IDE disks in particular.
If we agree that probing slow devices only once is a desireable goal, let's go for it. Otherwise I would just change your serial port info into a console / aux console info; the change is minimal.
Torsten