From: Patrick Ohly <patrick.ohly@intel.com>
To: Otavio Salvador <otavio.salvador@ossystems.com.br>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 04/10] initramfs-framework: add separate init_verbose log level parameter
Date: Thu, 03 Sep 2015 08:36:58 +0200 [thread overview]
Message-ID: <1441262218.9573.12.camel@intel.com> (raw)
In-Reply-To: <CAP9ODKrCzcUdfs9+GLsSe-ztS3c5BCmcLBPdmSayw-y9ZzPtkA@mail.gmail.com>
On Wed, 2015-09-02 at 13:16 -0300, Otavio Salvador wrote:
> On Wed, Sep 2, 2015 at 12:48 PM, Patrick Ohly <patrick.ohly@intel.com> wrote:
> > Using the general purpose "debug" and "verbose" kernel parameters to
> > increase logging in the init script has the disadvantage that it
> > also increases logging in other components, making the output hard
> > to read (in particular with "debug").
> >
> > The new init_verbose parameter only affects the init script:
> > init_verbose, init_verbose=1, init_verbose=true: enable just some info messages
> > init_verbose=2: debug messages
> >
> > Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
> > ---
> > meta/recipes-core/initrdscripts/initramfs-framework/init | 16 ++++++++++++++--
> > 1 file changed, 14 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta/recipes-core/initrdscripts/initramfs-framework/init b/meta/recipes-core/initrdscripts/initramfs-framework/init
> > index e8f4713..cd55ee2 100755
> > --- a/meta/recipes-core/initrdscripts/initramfs-framework/init
> > +++ b/meta/recipes-core/initrdscripts/initramfs-framework/init
> > @@ -14,6 +14,13 @@
> > # 'foo=value' as 'bootparam_foo=value'
> > # 'foo' as 'bootparam_foo=true'
> > # 'foo.bar[=value] as 'foo_bar=[value|true]'
> > +#
> > +# Special boot parameters always recognized by initramfs-framework (see modules
> > +# like "debug" for additional ones):
> > +# debug: enable debug logging (beware, also enables debug output in other system components)
> > +# verbose: similar do debug, just less output
> > +# init_verbose[=true|1|2]: same output as for verbose when no value or true/1 are given,
> > +# same as debug for 2 - only affects logging in initramfs-framework
>
> I personally don't see much benefit on this. The debug module is the
> one used to debug the initramfs-framework script. If we ought to add
> support for something like this, this should be done there.
So you are saying that the msg/info/debug/fatal functions should be in
the "debug" module? Or should they be present, but changing the logging
level should be done by the "debug" module? How would logging work
before the "debug" module is loaded or when it is not installed at all
(as in a production image)?
I guess one could have empty stubs in the main "init" and only do
logging after loading the debug module - that should work, at the loss
of early log output.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
next prev parent reply other threads:[~2015-09-03 6:37 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-02 15:48 [PATCH 00/10] enhancing images, booting and runqemu Patrick Ohly
2015-09-02 15:48 ` [PATCH 01/10] runqemu: support full-disk images Patrick Ohly
2015-09-02 15:48 ` [PATCH 02/10] initrdscripts: create /dev/console Patrick Ohly
2015-09-02 16:08 ` Otavio Salvador
2015-09-02 15:48 ` [PATCH 03/10] initramfs-framework: handle kernel parameters with . inside Patrick Ohly
2015-09-02 16:09 ` Otavio Salvador
2015-09-02 15:48 ` [PATCH 04/10] initramfs-framework: add separate init_verbose log level parameter Patrick Ohly
2015-09-02 16:16 ` Otavio Salvador
2015-09-03 6:36 ` Patrick Ohly [this message]
2015-09-03 11:50 ` Otavio Salvador
2015-09-02 15:48 ` [PATCH 05/10] initramfs-framework: support mounting rootfs in modules Patrick Ohly
2015-09-02 16:19 ` Otavio Salvador
2015-09-02 16:24 ` Otavio Salvador
2015-09-03 6:29 ` Patrick Ohly
2015-09-03 11:55 ` Otavio Salvador
2015-09-02 15:48 ` [PATCH 06/10] initramfs-framework: support live images Patrick Ohly
2015-09-02 15:48 ` [PATCH 07/10] image-vm.bbclass: avoid duplicating syslinux default values Patrick Ohly
2015-09-02 15:48 ` [PATCH 08/10] image-vm.bbclass: support specifying an initramfs Patrick Ohly
2015-09-02 15:48 ` [PATCH 09/10] boot loader: support root=UUID Patrick Ohly
2015-09-02 15:48 ` [PATCH 10/10] boot-directdisk.bbclass: use rootfs UUID by default Patrick Ohly
2015-09-02 16:28 ` [PATCH 00/10] enhancing images, booting and runqemu Otavio Salvador
2015-09-03 18:42 ` [PATCH 0/8] enhancing images, booting and runqemu, simplified version Patrick Ohly
2015-09-03 18:42 ` [PATCH 1/8] runqemu: support full-disk images Patrick Ohly
2015-09-03 18:42 ` [PATCH 2/8] initramfs-framework: create /dev/console Patrick Ohly
2015-09-03 21:34 ` Khem Raj
2015-09-04 7:08 ` Patrick Ohly
2015-09-03 18:42 ` [PATCH 3/8] initramfs-live-boot: " Patrick Ohly
2015-09-03 18:42 ` [PATCH 4/8] initramfs-framework: handle kernel parameters with . inside Patrick Ohly
2015-09-03 18:42 ` [PATCH 5/8] image-vm.bbclass: avoid duplicating syslinux default values Patrick Ohly
2015-09-03 18:42 ` [PATCH 6/8] image-vm.bbclass: support specifying an initramfs Patrick Ohly
2015-09-03 18:42 ` [PATCH 7/8] boot loader: support root=UUID Patrick Ohly
2015-09-03 18:42 ` [PATCH 8/8] boot-directdisk.bbclass: use rootfs UUID by default Patrick Ohly
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=1441262218.9573.12.camel@intel.com \
--to=patrick.ohly@intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=otavio.salvador@ossystems.com.br \
/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