From: Samo Pogacnik <samo_pogacnik@t-2.net>
To: Marco Stornelli <marco.stornelli@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
linux-embedded <linux-embedded@vger.kernel.org>,
linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] console logging detour via printk
Date: Sun, 02 May 2010 15:29:47 +0200 [thread overview]
Message-ID: <1272806987.2155.34.camel@itpsd6lap> (raw)
In-Reply-To: <4BDD4CD7.2060205@gmail.com>
Dne 02.05.2010 (ned) ob 11:58 +0200 je Marco Stornelli zapisal(a):
> 01/05/2010 20:48, Samo Pogacnik wrote:
> > Dne 01.05.2010 (sob) ob 12:04 +0100 je Alan Cox zapisal(a):
> >>> 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 you want to patch the kernel because you can't work out how to do this
> >> in userspace ? The distributions seem to have no problem doing this in
> >> user space that I can see. It doesn't seem to be a hard user space
> >> problem, and there are a ton of things you want to do with this sort of
> >> stuff (like network logging) that you can't do in kernel space.
> >
> > The distros have no problem logging complete console output into log
> > files or over the network, because they simply do not do it at least for
> > the initrd part of the boot process (i'd be glad, if i'm wrong).
>
> Mmm...It's an interesting problem. I see in my distro (openSuse) a
> script called boot.klog that it seems to perform that (even initrd
> part). In the file boot.msg I can see the initial prints of the kernel
> and user space scripts.
>
Thanks for the info.
Is this boot.klog script from the initrd image or from the real rootfs?
As you can see, i am still suspicious about the initrd part user console
messages:)
Samo
next prev parent reply other threads:[~2010-05-02 13:29 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
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 [this message]
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=1272806987.2155.34.camel@itpsd6lap \
--to=samo_pogacnik@t-2.net \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.stornelli@gmail.com \
/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.