[LinuxBIOS] v3: documentation fixes

[Jordan Crouse]

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 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.

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.

Jordan

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.