On Fri, 21 Sep 2007, Gerd Hoffmann wrote:

Well, I placed the printk there is for user interface reasons.  I think
especially in case the early console and the real console go to
different physical devices it is useful to have the reason it stops
printing messages displayed on the early console.  So people don't think
the computer hangs although it just prints messages elsewhere ...

 I have thought this might be the reason, but did not want to suggest 
anything.  Yes, it is useful in a way and I was bitten a few times in the 
past with the output disappearing on the boot console with no further 
output (and usually a complete hang) because of a problem in the real 
console driver.  It just happens I always knew which driver was involved.

If that isn't going to work due to two instances not knowing each other
(kernel & firmware) should not mess with the same physical device, then
I'd just drop the printk.  And I see no pretty and easy way around that
issue :-(

 Not so fast please. :-)

We could do the printk and unregister before we setup the new console.
Which has the drawback that we are in trouble in case the setup() call
for the new console fails ...

We could split the printk into two, one early ("trying to setup new
console foo") which goes to the boot console, then (assuming the setup
worked ok) unregister silently and print a message about the successful
init and boot console unregister on the new console only.  Which results
in two lines being printed for the handover when both consoles address
the same physical device.  Not that nice IMHO, but maybe still the best
way to handle it.

 I have thought of it too.  It is just the "for" loop responsible for 
doing this is somewhat convoluted so I did not want to proceed with a 
possibly complicated patch just to demonstrate the problem.

 I think it is not a bad approach and in some sense it could be nicer as 
would provide some feedback on which drivers are tried for the console.  
The drawback is if there are many candidate console drivers that may fail 
for some reason, like being optional for the platform, then a lot of 
output will result.  The way it could work might be by printing the:

handover: boot [<foo>] -> real [<bar>]

line to the boot console only and then printing:

console [<bar>] enabled

unconditionally if registering of <bar> succeeded and once <foo> has been 
unregistered.

 On the other hand the current approach has this limitation that if it 
actually works for a given platform, then the two lines may be printed to 
the same devices and overlap.  This is for example the case with the SWARM 
board (using drivers/serial/sb1250-duart.c) which also uses a firmware 
call for the initial console.  It does not seem to be that concerned about 
the transmitter being disabled, but it does not wait for the transmitter 
shift register to drain and output is garbled.  Here is an excerpt from a 
SWARM boot log as seen on the serial port (codes in agle brackets coming 
from the interpretation of non-ASCII characters by `less'):

PID hash table entries: 1024 (order: 10, 8192 bytes)
Using 1.000 MHz high precision timer.
Console: colour dum7<BD><B9><CD><BD><B1><95><81>handover: boot [early0] -> real [duart0]
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar

Though frankly it is even some previous line being destroyed here...

  Maciej