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 -- linuxbios mailing list linuxbios@linuxbios.org http://www.linuxbios.org/mailman/listinfo/linuxbios
