From: Dan Kegel <dank@kegel.com>
To: Russell King <rmk@arm.linux.org.uk>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: printk in init_module mixing with printf in insmod
Date: Fri, 19 Apr 2002 12:51:30 -0700 [thread overview]
Message-ID: <3CC07542.45E5267D@kegel.com> (raw)
In-Reply-To: <3CC06470.F05543C4@kegel.com> <20020419194703.A28850@flint.arm.linux.org.uk>
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
next prev parent reply other threads:[~2002-04-19 19:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-19 18:39 printk in init_module mixing with printf in insmod Dan Kegel
2002-04-19 18:47 ` Russell King
2002-04-19 19:51 ` Dan Kegel [this message]
2002-04-19 22:24 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3CC07542.45E5267D@kegel.com \
--to=dank@kegel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.