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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox