[LinuxBIOS] v3: documentation fixes
c-d.hailfinger.devel.2006 at gmx.net
Thu Nov 15 17:29:26 CET 2007
On 15.11.2007 17:20, Jordan Crouse wrote:
> On 15/11/07 11:45 +0100, Carl-Daniel Hailfinger wrote:
>> On 15.11.2007 01:32, Jordan Crouse wrote:
>>> I think printk is always available - any previous printk pain has been
>>> (finally) resolved.
>> That warrants updating the design doc as well as another question: Is
>> printk available before early serial port setup? AFAICS it is not. We
>> have to differentiate between 4 stages (not in our stage sense) for printk:
>> 1. No CAR, no RAM, no early serial - > printk is not feasible
>> 2. CAR, but no RAM, no early serial -> printk to an internal buffer
>> could work, but the user can't see that
>> 3. CAR, early serial, but no RAM -> printk to serial works
>> 4. (much later) RAM, serial, VGA -> printk to serial and VGA works
>> When do we want to declare printk as usable?
> The question is - do we care? Technically, the printk guts should be
> smart enough to know if it can use the outputs or not - either by
> purposely returning early, or maybe just by pushing bits to an I/O
> port that isn't listening yet.
If pushing bits to a non-listening I/O port is harmless, that's nice.
> If you, as a developer happen to printk() before that point,
> then you will miss your message, that is true. To me that is far better
> then trying to impose a self-policed moratorium on using printk() too
> early, which despite all the documentation in the world, somebody is bound
> to ignore or screw up. Imposing restrictions on developers without
> software or hardware enforcement will only end in disaster.
OK, I'll make sure printk gets a bit smarter and update the docs.
> The fun part is that it will just work out in the end. Developers who
> have a reason to be adding printks to very early init (pre raminit) will
> probably also be the ones who are adding the early serial code too.
Thanks for the explanation. Expect patches.
More information about the coreboot