[LinuxBIOS] v3: documentation fixes

[Carl-Daniel Hailfinger]

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.

Regards,
Carl-Daniel