From: Samo Pogacnik <samo_pogacnik@t-2.net>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-embedded <linux-embedded@vger.kernel.org>,
linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] console logging detour via printk
Date: Sat, 01 May 2010 18:36:54 +0200 [thread overview]
Message-ID: <1272731814.2147.26.camel@itpsd6lap> (raw)
In-Reply-To: <z2r10f740e81005010200we353e3a4v90d9fe64620edb24@mail.gmail.com>
Dne 01.05.2010 (sob) ob 11:00 +0200 je Geert Uytterhoeven zapisal(a):
> On Sat, May 1, 2010 at 00:03, Samo Pogacnik <samo_pogacnik@t-2.net> wrote:
> > while i was searching for effective logging of complete console output
> > produced by the kernel and user phase of the boot process, it turned out
> > that only kernel messages imho get systematically cached and stored into
> > log files (if needed). All userspace processes are on their own to use
> > syslog, which is fine, but there are also many console messages
> > reporting the boot status via init scripts, .... I came across the
> > bootlogd daemo, which handles the job of redirecting console output into
> > a log file, but i find it problematic to use especialy, when using
> > initial ram disk image.
> >
> > So in short i came up with an idea to transform console writes into
> > printks at appropriate code place of some console drivers (the patch
> > includes code for VT console and SERIAL_CORE console drivers). Printks
> > eventually reach console device avoiding the patched part of the console
> > drivers.
>
> What about catching /dev/console instead of VT console, SERIAL_CORE
> console, ...?
> Then it works with whatever console= parameter you specify.
Could not agree more, but that was as close as i was able to detect the
common code and provide something that actually works. Maybe this is
already enough to cover all boot consoles?
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
regards, Samo
next prev parent reply other threads:[~2010-05-01 16:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-30 22:03 [PATCH] console logging detour via printk Samo Pogacnik
2010-04-30 22:45 ` Randy Dunlap
2010-05-01 8:37 ` Samo Pogacnik
2010-05-01 22:23 ` Samo Pogacnik
2010-05-01 9:00 ` Geert Uytterhoeven
2010-05-01 16:36 ` Samo Pogacnik [this message]
2010-05-01 21:03 ` Samo Pogacnik
2010-05-01 11:04 ` Alan Cox
2010-05-01 18:48 ` Samo Pogacnik
2010-05-01 19:41 ` Alan Cox
2010-05-01 22:45 ` Samo Pogacnik
2010-05-02 9:58 ` Marco Stornelli
2010-05-02 13:29 ` Samo Pogacnik
2010-05-03 17:05 ` Marco Stornelli
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=1272731814.2147.26.camel@itpsd6lap \
--to=samo_pogacnik@t-2.net \
--cc=geert@linux-m68k.org \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.