printk in init_module mixing with printf in insmod

printk in init_module mixing with printf in insmod

[Dan Kegel]

I recently upgraded my ppc405 embedded system
from 2.4.2 or so to 2.4.17 or so.  I use modutils-2.4.12.
When I insert a nongpl module, 
the 
  fprintf(stderr, "Warning: loading foo.o will taint kernel\n");
in insmod and the
  printk("Hello, world\n");
in the module are intermixed unpleasantly, yielding output like
    Warning: loHello,ading foo.o world
    will taint kernel

This garbled output makes reading the debugging printk's difficult.

I suppose this isn't terribly important, since printk's are
kind of a no-no in production, and this only affects printk's
in init_module, but it'd be nice to know what
the cleanest way to get rid of the mixing is.  Adding a sleep
inside insmod seems heavyhanded.  I suppose I could redirect
insmod's output to a file, sleep a bit, and then display the 
file... bleah.
- Dan

Re: printk in init_module mixing with printf in insmod

[Russell King]

On Fri, Apr 19, 2002 at 11:39:44AM -0700, Dan Kegel wrote:
> I suppose this isn't terribly important, since printk's are
> kind of a no-no in production, and this only affects printk's
> in init_module, but it'd be nice to know what
> the cleanest way to get rid of the mixing is.  Adding a sleep
> inside insmod seems heavyhanded.  I suppose I could redirect
> insmod's output to a file, sleep a bit, and then display the 
> file... bleah.

Output from a program to a serial port is buffered, and is thus
asynchronous to the program.  printk output is synchronous, and as
such will interrupt the normal IO to the port.

If you're going to use delays, you need to take account of the serial
port baud rate and adjust the delay accordingly.  However, you don't
really know how many characters are pending in the kernel anyway.

I don't think there's an answer to this if you're going to run both
applications and kernel console on the same port.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: printk in init_module mixing with printf in insmod

[Dan Kegel]

Russell King wrote:
> 
> On Fri, Apr 19, 2002 at 11:39:44AM -0700, Dan Kegel wrote:
> > I suppose this isn't terribly important, since printk's are
> > kind of a no-no in production, and this only affects printk's
> > in init_module, but it'd be nice to know what
> > the cleanest way to get rid of the mixing is.  Adding a sleep
> > inside insmod seems heavyhanded.  I suppose I could redirect
> > insmod's output to a file, sleep a bit, and then display the
> > file... bleah.
> 
> Output from a program to a serial port is buffered, and is thus
> asynchronous to the program.  printk output is synchronous, and as
> such will interrupt the normal IO to the port.
> 
> If you're going to use delays, you need to take account of the serial
> port baud rate and adjust the delay accordingly.  However, you don't
> really know how many characters are pending in the kernel anyway.

Thanks for the info.

For now, I'm just kludging in a sleep(1) in insmod right after
the print, as a temporary fix for my particular needs.  Saves
me editing lots of source files, and it "works" for this particular
situation.

> I don't think there's an answer to this if you're going to run both
> applications and kernel console on the same port.

insmod is run by /etc/init.d/rcS, so it's kind of unavoidable.
But I'm happy with my little private kludge for now.
- Dan

Re: printk in init_module mixing with printf in insmod

[Alan Cox]

>   printk("Hello, world\n");
> in the module are intermixed unpleasantly, yielding output like
>     Warning: loHello,ading foo.o world
>     will taint kernel
> 
> This garbled output makes reading the debugging printk's difficult.
> 
> I suppose this isn't terribly important, since printk's are
> kind of a no-no in production, and this only affects printk's
> in init_module, but it'd be nice to know what
> the cleanest way to get rid of the mixing is.  Adding a sleep
> inside insmod seems heavyhanded.  I suppose I could redirect
> insmod's output to a file, sleep a bit, and then display the 
> file... bleah.

Probably you want to fprintf the message after the module initialise has
reported completion, instead of before. I see no good way of hiding it
the other way around.