Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug

2014-04-08 Thread Jason St. John 
On Sat, Apr 5, 2014 at 9:26 PM, David Timothy Strauss
da...@davidstrauss.net wrote:
 On Sat, Apr 5, 2014 at 4:06 PM, Jason St. John jstj...@purdue.edu wrote:
 init.debug would be better than systemd.debug, in my opinion. It
 is shorter (less typing and no possible end-user confusion over
 systemd.debug vs. system.debug), and it is init-agnostic. Other
 init systems (OpenRC, Upstart, etc.) would be able to add their own
 support for this, if they want, without requiring an init-specific
 kernel parameter.

 It just seems a lot simpler this way.

 It would be a little odd given how systemd.name is how other
 probably portable options get namespaced. Arguably, systemd.log_level
 would become init.log_level. I'm not against it, but it couldn't be
 just init.debug.

That's a good point. Would patches be accepted that allowed both
systemd.log_level and init.log_level, etc.?

Jason
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug

2014-04-05 Thread Greg KH 
On Sat, Apr 05, 2014 at 07:11:47AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
 On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote:
  From: Greg KH gre...@linuxfoundation.org
  
  If the kernel is started with debug, that's for the kernel to switch
  into debug mode.  We should rely on a namespace for our options, like
  everything else (with the exception of quiet).  Some people want to
  only debug the kernel, not systemd, and the opposite as well so make
  everyone happy.
 Essentialy, this patch adds systemd.debug as an alias for
 systemd.log_level=debug systemd.log_target=console. But it doesn't
 really fix anything, just moves the initial problem to a different set
 of options.

What needs to be fixed?

 This isn't useful. In addition, it is reasonable to use debug to
 turn on verbose mode for the kernel + init combo, since in practice
 this is what people need to diagnose boot problems.

Well, the intersection of people that have a problem with both the
kernel and systemd at boot time are probably quite small.  As a kernel
developer, I tell people to turn on debug all the time to find issues in
different drivers and the like.  They aren't having any problems with
systemd, so any extra messages that it causes, isn't going to be
helpful.

Probably the same thing happens for people who are having problems with
systemd.

So I thought it would make more sense to have separate options, as the
two things really are two different projects / code bases.  Having the
same flag makes it easy for a small subset of people who would be doing
work in both areas, and even then, having to add a simple
systemd.debug flag to the command line for that doesn't seem to be a
big deal.

thanks,

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug

2014-04-05 Thread Zbigniew Jędrzejewski-Szmek 
On Sat, Apr 05, 2014 at 01:16:12PM -0700, Greg KH wrote:
 On Sat, Apr 05, 2014 at 07:11:47AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
  On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote:
   From: Greg KH gre...@linuxfoundation.org
   
   If the kernel is started with debug, that's for the kernel to switch
   into debug mode.  We should rely on a namespace for our options, like
   everything else (with the exception of quiet).  Some people want to
   only debug the kernel, not systemd, and the opposite as well so make
   everyone happy.
  Essentialy, this patch adds systemd.debug as an alias for
  systemd.log_level=debug systemd.log_target=console. But it doesn't
  really fix anything, just moves the initial problem to a different set
  of options.
 
 What needs to be fixed?
The fact that kernel in debug + systemd in debug mode mode produced
enough data to case a failed boot. I didn't follow the details of what
exactly broke, but at least systemd is (was?) logging a stupid
assertion.

  This isn't useful. In addition, it is reasonable to use debug to
  turn on verbose mode for the kernel + init combo, since in practice
  this is what people need to diagnose boot problems.
 
 Well, the intersection of people that have a problem with both the
 kernel and systemd at boot time are probably quite small.  As a kernel
 developer, I tell people to turn on debug all the time to find issues in
 different drivers and the like.  They aren't having any problems with
 systemd, so any extra messages that it causes, isn't going to be
 helpful.
It's a tradeoff, and there are cases where one meaning or the other
would be more convenient. We can certainly find lots or examples and
counterexamples... E.g. for me the recent slew of issues with boot
getting stuck in F20, which seemed to have been caused by a
combination of kernel, systemd, plymouth, and gdm or kdm issues, was
quite important and visible. Having 'debug' as one-stop option for
less experienced users was totally appropriate.

In fact, this setting has been interpreted this way by systemd for a
while now, and this bug report is the first complaint about that that
I'm aware of.

The whole issue started with bug #76935: the original reporter was
seemingly unaware of available kernel commandline options, and his
comments fairly quickly degenerated to rude personal attacks. It's
something that one sees quite often: a complaint, a reply how
requested goals can be achieved and why things are implemented the way
they are, followed by demands of having it my way, followed by a fit
and swearing. Then come Anonymous Helpers. I really don't see why we
should deal with this shit and waste time on people who evidently want
to vent their frustration rather than solve a bug.

 Probably the same thing happens for people who are having problems with
 systemd.
 
 So I thought it would make more sense to have separate options, as the
 two things really are two different projects / code bases.  Having the
 same flag makes it easy for a small subset of people who would be doing
 work in both areas, and even then, having to add a simple
 systemd.debug flag to the command line for that doesn't seem to be a
 big deal.
We already have systemd.log_level=debug which is well known... And
usually systemd debugging is most useful together with kernel debugging,
so the shared interpretation makes the most sense for us.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug

2014-04-05 Thread Tom Gundersen 
On Sat, Apr 5, 2014 at 11:22 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Sat, Apr 05, 2014 at 01:16:12PM -0700, Greg KH wrote:
 On Sat, Apr 05, 2014 at 07:11:47AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
  On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote:
   From: Greg KH gre...@linuxfoundation.org
  
   If the kernel is started with debug, that's for the kernel to switch
   into debug mode.  We should rely on a namespace for our options, like
   everything else (with the exception of quiet).  Some people want to
   only debug the kernel, not systemd, and the opposite as well so make
   everyone happy.
  Essentialy, this patch adds systemd.debug as an alias for
  systemd.log_level=debug systemd.log_target=console. But it doesn't
  really fix anything, just moves the initial problem to a different set
  of options.

 What needs to be fixed?
 The fact that kernel in debug + systemd in debug mode mode produced
 enough data to case a failed boot. I didn't follow the details of what
 exactly broke, but at least systemd is (was?) logging a stupid
 assertion.

  This isn't useful. In addition, it is reasonable to use debug to
  turn on verbose mode for the kernel + init combo, since in practice
  this is what people need to diagnose boot problems.

 Well, the intersection of people that have a problem with both the
 kernel and systemd at boot time are probably quite small.  As a kernel
 developer, I tell people to turn on debug all the time to find issues in
 different drivers and the like.  They aren't having any problems with
 systemd, so any extra messages that it causes, isn't going to be
 helpful.
 It's a tradeoff, and there are cases where one meaning or the other
 would be more convenient. We can certainly find lots or examples and
 counterexamples... E.g. for me the recent slew of issues with boot
 getting stuck in F20, which seemed to have been caused by a
 combination of kernel, systemd, plymouth, and gdm or kdm issues, was
 quite important and visible. Having 'debug' as one-stop option for
 less experienced users was totally appropriate.

 In fact, this setting has been interpreted this way by systemd for a
 while now, and this bug report is the first complaint about that that
 I'm aware of.

 The whole issue started with bug #76935: the original reporter was
 seemingly unaware of available kernel commandline options, and his
 comments fairly quickly degenerated to rude personal attacks. It's
 something that one sees quite often: a complaint, a reply how
 requested goals can be achieved and why things are implemented the way
 they are, followed by demands of having it my way, followed by a fit
 and swearing. Then come Anonymous Helpers. I really don't see why we
 should deal with this shit and waste time on people who evidently want
 to vent their frustration rather than solve a bug.

 Probably the same thing happens for people who are having problems with
 systemd.

 So I thought it would make more sense to have separate options, as the
 two things really are two different projects / code bases.  Having the
 same flag makes it easy for a small subset of people who would be doing
 work in both areas, and even then, having to add a simple
 systemd.debug flag to the command line for that doesn't seem to be a
 big deal.
 We already have systemd.log_level=debug which is well known... And
 usually systemd debugging is most useful together with kernel debugging,
 so the shared interpretation makes the most sense for us.

Btw, I don't think what makes the most sense to us (systemd devs) is
really that important, nor what makes sense to kernel devs. All of us
are more than capable of passing whatever combination of commandline
options necessary to get the effect we want. What we should care about
is people who don't spend all their time debugging kernel/init. I.e.,
end-users, support channels, etc. As long as people are not even
arguing from that point of view, I don't think we will get anywhere
with this...

-t
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug

2014-04-05 Thread Reindl Harald 

Am 05.04.2014 23:22, schrieb Zbigniew Jędrzejewski-Szmek:
 The whole issue started with bug #76935: the original reporter was
 seemingly unaware of available kernel commandline options, and his
 comments fairly quickly degenerated to rude personal attacks. It's
 something that one sees quite often: a complaint, a reply how
 requested goals can be achieved and why things are implemented the way
 they are, followed by demands of having it my way, followed by a fit
 and swearing. Then come Anonymous Helpers. I really don't see why we
 should deal with this shit and waste time on people who evidently want
 to vent their frustration rather than solve a bug.

cause and effect, the rude attacks maybe because ignorance
and frustration about the we are always right attitude

what makes sense *to you* is not the only relevant thing!

http://lkml.org/lkml/2012/10/3/484
http://www.spinics.net/lists/kernel/msg1716484.html
https://plus.google.com/u/0/+TheodoreTso/posts/K7ijdmxJ8PF

i guess Kay will now remove me from that list because as affected user i have
to shut up in general but that does not change anything in casue and effect
and that there are enough people with zero understanding for I really don't
see why we should deal with this shit which is your userbase - if you are
not interested in users you should make a private project but not the first
most imporant piece after the kernel because that brings *responsibility*
___

no other software than systemd logs that much to *bury*
any for a non-systemd-developer relevant infos even under
normal operations

http://www.spinics.net/lists/kernel/msg1716484.html
Linus words I personally find it annoying that it's always
the same f*cking primadonna involved are hardly because
*that one* thing and should lead to consider things are
handeled wrong instead continue with I really don't see why we
should deal with this shit

the following parapgraph talks also about a general attitude
that anybody with critism is treated as enemy all the time
and everything left and right of systemd is broken in general
and has to be fixed because it stands in the way of systemd

 It does become a problem when you have a system service developer who
 thinks the universe revolves around him, and nobody else matters, and
 people sending him bug-reports are annoyances that should be ignored
 rather than acknowledged and fixed. At that point, it's a problem.




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug

2014-04-05 Thread Zbigniew Jędrzejewski-Szmek 
On Sat, Apr 05, 2014 at 11:32:50PM +0200, Tom Gundersen wrote:
 On Sat, Apr 5, 2014 at 11:22 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
  On Sat, Apr 05, 2014 at 01:16:12PM -0700, Greg KH wrote:
  On Sat, Apr 05, 2014 at 07:11:47AM +0200, Zbigniew Jędrzejewski-Szmek 
  wrote:
   On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote:
From: Greg KH gre...@linuxfoundation.org
   
If the kernel is started with debug, that's for the kernel to switch
into debug mode.  We should rely on a namespace for our options, like
everything else (with the exception of quiet).  Some people want to
only debug the kernel, not systemd, and the opposite as well so make
everyone happy.
   Essentialy, this patch adds systemd.debug as an alias for
   systemd.log_level=debug systemd.log_target=console. But it doesn't
   really fix anything, just moves the initial problem to a different set
   of options.
 
  What needs to be fixed?
  The fact that kernel in debug + systemd in debug mode mode produced
  enough data to case a failed boot. I didn't follow the details of what
  exactly broke, but at least systemd is (was?) logging a stupid
  assertion.
 
   This isn't useful. In addition, it is reasonable to use debug to
   turn on verbose mode for the kernel + init combo, since in practice
   this is what people need to diagnose boot problems.
 
  Well, the intersection of people that have a problem with both the
  kernel and systemd at boot time are probably quite small.  As a kernel
  developer, I tell people to turn on debug all the time to find issues in
  different drivers and the like.  They aren't having any problems with
  systemd, so any extra messages that it causes, isn't going to be
  helpful.
  It's a tradeoff, and there are cases where one meaning or the other
  would be more convenient. We can certainly find lots or examples and
  counterexamples... E.g. for me the recent slew of issues with boot
  getting stuck in F20, which seemed to have been caused by a
  combination of kernel, systemd, plymouth, and gdm or kdm issues, was
  quite important and visible. Having 'debug' as one-stop option for
  less experienced users was totally appropriate.
 
  In fact, this setting has been interpreted this way by systemd for a
  while now, and this bug report is the first complaint about that that
  I'm aware of.
 
  The whole issue started with bug #76935: the original reporter was
  seemingly unaware of available kernel commandline options, and his
  comments fairly quickly degenerated to rude personal attacks. It's
  something that one sees quite often: a complaint, a reply how
  requested goals can be achieved and why things are implemented the way
  they are, followed by demands of having it my way, followed by a fit
  and swearing. Then come Anonymous Helpers. I really don't see why we
  should deal with this shit and waste time on people who evidently want
  to vent their frustration rather than solve a bug.
 
  Probably the same thing happens for people who are having problems with
  systemd.
 
  So I thought it would make more sense to have separate options, as the
  two things really are two different projects / code bases.  Having the
  same flag makes it easy for a small subset of people who would be doing
  work in both areas, and even then, having to add a simple
  systemd.debug flag to the command line for that doesn't seem to be a
  big deal.
  We already have systemd.log_level=debug which is well known... And
  usually systemd debugging is most useful together with kernel debugging,
  so the shared interpretation makes the most sense for us.
 
 Btw, I don't think what makes the most sense to us (systemd devs) is
 really that important, nor what makes sense to kernel devs. All of us
 are more than capable of passing whatever combination of commandline
 options necessary to get the effect we want. What we should care about
 is people who don't spend all their time debugging kernel/init. I.e.,
 end-users, support channels, etc. As long as people are not even
 arguing from that point of view, I don't think we will get anywhere
 with this...
Well, the example with F20 boot bugs I cite was exactly about that.

  Having 'debug' as one-stop option for
  less experienced users was totally appropriate.

Zbyszek

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug

2014-04-05 Thread Tom Gundersen 
On Sat, Apr 5, 2014 at 11:44 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Sat, Apr 05, 2014 at 11:32:50PM +0200, Tom Gundersen wrote:
 On Sat, Apr 5, 2014 at 11:22 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
  On Sat, Apr 05, 2014 at 01:16:12PM -0700, Greg KH wrote:
  On Sat, Apr 05, 2014 at 07:11:47AM +0200, Zbigniew Jędrzejewski-Szmek 
  wrote:
   On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote:
From: Greg KH gre...@linuxfoundation.org
   
If the kernel is started with debug, that's for the kernel to switch
into debug mode.  We should rely on a namespace for our options, like
everything else (with the exception of quiet).  Some people want to
only debug the kernel, not systemd, and the opposite as well so make
everyone happy.
   Essentialy, this patch adds systemd.debug as an alias for
   systemd.log_level=debug systemd.log_target=console. But it doesn't
   really fix anything, just moves the initial problem to a different set
   of options.
 
  What needs to be fixed?
  The fact that kernel in debug + systemd in debug mode mode produced
  enough data to case a failed boot. I didn't follow the details of what
  exactly broke, but at least systemd is (was?) logging a stupid
  assertion.
 
   This isn't useful. In addition, it is reasonable to use debug to
   turn on verbose mode for the kernel + init combo, since in practice
   this is what people need to diagnose boot problems.
 
  Well, the intersection of people that have a problem with both the
  kernel and systemd at boot time are probably quite small.  As a kernel
  developer, I tell people to turn on debug all the time to find issues in
  different drivers and the like.  They aren't having any problems with
  systemd, so any extra messages that it causes, isn't going to be
  helpful.
  It's a tradeoff, and there are cases where one meaning or the other
  would be more convenient. We can certainly find lots or examples and
  counterexamples... E.g. for me the recent slew of issues with boot
  getting stuck in F20, which seemed to have been caused by a
  combination of kernel, systemd, plymouth, and gdm or kdm issues, was
  quite important and visible. Having 'debug' as one-stop option for
  less experienced users was totally appropriate.
 
  In fact, this setting has been interpreted this way by systemd for a
  while now, and this bug report is the first complaint about that that
  I'm aware of.
 
  The whole issue started with bug #76935: the original reporter was
  seemingly unaware of available kernel commandline options, and his
  comments fairly quickly degenerated to rude personal attacks. It's
  something that one sees quite often: a complaint, a reply how
  requested goals can be achieved and why things are implemented the way
  they are, followed by demands of having it my way, followed by a fit
  and swearing. Then come Anonymous Helpers. I really don't see why we
  should deal with this shit and waste time on people who evidently want
  to vent their frustration rather than solve a bug.
 
  Probably the same thing happens for people who are having problems with
  systemd.
 
  So I thought it would make more sense to have separate options, as the
  two things really are two different projects / code bases.  Having the
  same flag makes it easy for a small subset of people who would be doing
  work in both areas, and even then, having to add a simple
  systemd.debug flag to the command line for that doesn't seem to be a
  big deal.
  We already have systemd.log_level=debug which is well known... And
  usually systemd debugging is most useful together with kernel debugging,
  so the shared interpretation makes the most sense for us.

 Btw, I don't think what makes the most sense to us (systemd devs) is
 really that important, nor what makes sense to kernel devs. All of us
 are more than capable of passing whatever combination of commandline
 options necessary to get the effect we want. What we should care about
 is people who don't spend all their time debugging kernel/init. I.e.,
 end-users, support channels, etc. As long as people are not even
 arguing from that point of view, I don't think we will get anywhere
 with this...
 Well, the example with F20 boot bugs I cite was exactly about that.

Yes, indeed you did cover that. Bad phrasing from my side. What I
meant is that the counter argument (i.e., the argument why we should
change the current behavior) is not being made in terms of what is the
most useful to the majority of our user-base, merely what is the most
useful to kernel developers...

-t
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug

2014-04-05 Thread Jason St. John 
On Sat, Apr 5, 2014 at 4:16 PM, Greg KH gre...@linuxfoundation.org wrote:
 On Sat, Apr 05, 2014 at 07:11:47AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
 On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote:
  From: Greg KH gre...@linuxfoundation.org
 
  If the kernel is started with debug, that's for the kernel to switch
  into debug mode.  We should rely on a namespace for our options, like
  everything else (with the exception of quiet).  Some people want to
  only debug the kernel, not systemd, and the opposite as well so make
  everyone happy.
 Essentialy, this patch adds systemd.debug as an alias for
 systemd.log_level=debug systemd.log_target=console. But it doesn't
 really fix anything, just moves the initial problem to a different set
 of options.

 What needs to be fixed?

 This isn't useful. In addition, it is reasonable to use debug to
 turn on verbose mode for the kernel + init combo, since in practice
 this is what people need to diagnose boot problems.

 Well, the intersection of people that have a problem with both the
 kernel and systemd at boot time are probably quite small.  As a kernel
 developer, I tell people to turn on debug all the time to find issues in
 different drivers and the like.  They aren't having any problems with
 systemd, so any extra messages that it causes, isn't going to be
 helpful.

 Probably the same thing happens for people who are having problems with
 systemd.

 So I thought it would make more sense to have separate options, as the
 two things really are two different projects / code bases.  Having the
 same flag makes it easy for a small subset of people who would be doing
 work in both areas, and even then, having to add a simple
 systemd.debug flag to the command line for that doesn't seem to be a
 big deal.

 thanks,

 greg k-h

init.debug would be better than systemd.debug, in my opinion. It
is shorter (less typing and no possible end-user confusion over
systemd.debug vs. system.debug), and it is init-agnostic. Other
init systems (OpenRC, Upstart, etc.) would be able to add their own
support for this, if they want, without requiring an init-specific
kernel parameter.

It just seems a lot simpler this way.

Jason
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug

2014-04-05 Thread David Timothy Strauss 
On Sat, Apr 5, 2014 at 4:06 PM, Jason St. John jstj...@purdue.edu wrote:
 init.debug would be better than systemd.debug, in my opinion. It
 is shorter (less typing and no possible end-user confusion over
 systemd.debug vs. system.debug), and it is init-agnostic. Other
 init systems (OpenRC, Upstart, etc.) would be able to add their own
 support for this, if they want, without requiring an init-specific
 kernel parameter.

 It just seems a lot simpler this way.

It would be a little odd given how systemd.name is how other
probably portable options get namespaced. Arguably, systemd.log_level
would become init.log_level. I'm not against it, but it couldn't be
just init.debug.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug

2014-04-04 Thread Zbigniew Jędrzejewski-Szmek 
On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote:
 From: Greg KH gre...@linuxfoundation.org
 
 If the kernel is started with debug, that's for the kernel to switch
 into debug mode.  We should rely on a namespace for our options, like
 everything else (with the exception of quiet).  Some people want to
 only debug the kernel, not systemd, and the opposite as well so make
 everyone happy.
Essentialy, this patch adds systemd.debug as an alias for
systemd.log_level=debug systemd.log_target=console. But it doesn't
really fix anything, just moves the initial problem to a different set
of options. This isn't useful. In addition, it is reasonable to use
debug to turn on verbose mode for the kernel + init combo, since in
practice this is what people need to diagnose boot problems.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug

2014-04-03 Thread Hannes Reinecke 
From: Greg KH gre...@linuxfoundation.org

If the kernel is started with debug, that's for the kernel to switch
into debug mode.  We should rely on a namespace for our options, like
everything else (with the exception of quiet).  Some people want to
only debug the kernel, not systemd, and the opposite as well so make
everyone happy.

Signed-off-by: Greg KH gre...@linuxfoundation.org
Signed-off-by: Hannes Reinecke h...@suse.de
---
 man/kernel-command-line.xml |  4 ++--
 src/core/main.c | 21 +++--
 2 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/man/kernel-command-line.xml b/man/kernel-command-line.xml
index dbfec61..19da7a3 100644
--- a/man/kernel-command-line.xml
+++ b/man/kernel-command-line.xml
@@ -126,10 +126,10 @@
 /varlistentry
 
 varlistentry
-termvarnamedebug/varname/term
+termvarnamesystemd.debug/varname/term
 listitem
 paraParameter understood by
-both the kernel and the system
+the system
 and service manager to control
 console log verbosity. For
 details, see
diff --git a/src/core/main.c b/src/core/main.c
index 41605ee..2ca038c 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -374,6 +374,15 @@ static int parse_proc_cmdline_item(const char *key, const 
char *value) {
 } else
 log_warning(Environment variable name '%s' is not 
valid. Ignoring., value);
 
+} else if (streq(key, systemd.debug)  !value) {
+
+/* Log to kmsg, the journal socket will fill up before the
+ * journal is started and tools running during that time
+ * will block with every log message for for 60 seconds,
+ * before they give up. */
+log_set_max_level(LOG_DEBUG);
+log_set_target(detect_container(NULL)  0 ? LOG_TARGET_CONSOLE 
: LOG_TARGET_KMSG);
+
 } else if (!streq(key, systemd.restore_state) 
!streq(key, systemd.gpt_auto) 
(startswith(key, systemd.) || startswith(key, 
rd.systemd.))) {
@@ -408,7 +417,8 @@ static int parse_proc_cmdline_item(const char *key, const 
char *value) {
  
systemd.default_standard_error=null|tty|syslog|syslog+console|kmsg|kmsg+console|journal|journal+console\n
   Set 
default log error output for services\n
  systemd.setenv=ASSIGNMENTSet 
an environment variable for all spawned processes\n
- systemd.restore_state=0|1
Restore backlight/rfkill state at boot\n);
+ systemd.restore_state=0|1
Restore backlight/rfkill state at boot\n
+ systemd.debug
Enable debugging output\n);
 }
 
 } else if (streq(key, quiet)  !value) {
@@ -416,15 +426,6 @@ static int parse_proc_cmdline_item(const char *key, const 
char *value) {
 if (arg_show_status == _SHOW_STATUS_UNSET)
 arg_show_status = SHOW_STATUS_AUTO;
 
-} else if (streq(key, debug)  !value) {
-
-/* Log to kmsg, the journal socket will fill up before the
- * journal is started and tools running during that time
- * will block with every log message for for 60 seconds,
- * before they give up. */
-log_set_max_level(LOG_DEBUG);
-log_set_target(detect_container(NULL)  0 ? LOG_TARGET_CONSOLE 
: LOG_TARGET_KMSG);
-
 } else if (!in_initrd()  !value) {
 unsigned i;
 
-- 
1.8.1.4

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug

2014-04-03 Thread Greg KH 
On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote:
 From: Greg KH gre...@linuxfoundation.org
 
 If the kernel is started with debug, that's for the kernel to switch
 into debug mode.  We should rely on a namespace for our options, like
 everything else (with the exception of quiet).  Some people want to
 only debug the kernel, not systemd, and the opposite as well so make
 everyone happy.
 
 Signed-off-by: Greg KH gre...@linuxfoundation.org

Again, I never added this line :(

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not debug

2014-04-03 Thread Greg KH 
On Thu, Apr 03, 2014 at 08:18:26AM -0700, Greg KH wrote:
 On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote:
  From: Greg KH gre...@linuxfoundation.org
  
  If the kernel is started with debug, that's for the kernel to switch
  into debug mode.  We should rely on a namespace for our options, like
  everything else (with the exception of quiet).  Some people want to
  only debug the kernel, not systemd, and the opposite as well so make
  everyone happy.
  
  Signed-off-by: Greg KH gre...@linuxfoundation.org
 
 Again, I never added this line :(

That being said, your modification of my original patch looks correct,
thanks for doing that.

greg k-h
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel