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:
- No CAR, no RAM, no early serial - > printk is not feasible
- 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