Patch suggestion - logs cleanup

Patch suggestion - logs cleanup

[Ildar Muslukhov]

How about cleaning up source from all the printf and converting them
to the output? I am willing to do that, since would like to have more
control over logging and output.

Re: Patch suggestion - logs cleanup

[Dave Jones]

On Wed, Oct 02, 2013 at 05:04:50PM -0700, Ildar Muslukhov wrote:
 > How about cleaning up source from all the printf and converting them
 > to the output? I am willing to do that, since would like to have more
 > control over logging and output.

yeah, worth doing. Careful though, some of the printf's happen before we've opened
the log files.

Sort of related: At some point I think debugf needs to log to a separate debug log file.

	Dave

Re: Patch suggestion - logs cleanup

[Ildar Muslukhov]

Sure, let me deal with the printf first and then I will take a look at
debugf. BTW, before I jump to printf, can I ask you to push the last
patch I've sent, just want to avoid painful merge after with it, since
it does move some printf around a bit.

On Wed, Oct 2, 2013 at 5:11 PM, Dave Jones <davej@redhat.com> wrote:
> On Wed, Oct 02, 2013 at 05:04:50PM -0700, Ildar Muslukhov wrote:
>  > How about cleaning up source from all the printf and converting them
>  > to the output? I am willing to do that, since would like to have more
>  > control over logging and output.
>
> yeah, worth doing. Careful though, some of the printf's happen before we've opened
> the log files.
>
> Sort of related: At some point I think debugf needs to log to a separate debug log file.
>
>         Dave
>

Re: Patch suggestion - logs cleanup

[Dave Jones]

On Thu, Oct 03, 2013 at 10:31:03AM -0700, Ildar Muslukhov wrote:
 > Sure, let me deal with the printf first and then I will take a look at
 > debugf. BTW, before I jump to printf, can I ask you to push the last
 > patch I've sent, just want to avoid painful merge after with it, since
 > it does move some printf around a bit.
 
done, thanks.

	Dave

Re: Patch suggestion - logs cleanup

[Ildar Muslukhov]

What do you think if we combine -l, -q and -v parameters in the following way:
absence of the parameter will set log level to base (1)
-l off will work as it is right now (logging is off)
-l N is setup of the level (i.e., -l 1 will be equal to the default
settings, where N can be from 0 to 2 as it is right now).

This way we can simplify the log handling from source code point of
view. Having three parameters which might collide with each other
seems rather error prone.

On Thu, Oct 3, 2013 at 10:50 AM, Dave Jones <davej@redhat.com> wrote:
> On Thu, Oct 03, 2013 at 10:31:03AM -0700, Ildar Muslukhov wrote:
>  > Sure, let me deal with the printf first and then I will take a look at
>  > debugf. BTW, before I jump to printf, can I ask you to push the last
>  > patch I've sent, just want to avoid painful merge after with it, since
>  > it does move some printf around a bit.
>
> done, thanks.
>
>         Dave

Re: Patch suggestion - logs cleanup

[Dave Jones]

On Fri, Oct 04, 2013 at 12:34:35PM -0700, Ildar Muslukhov wrote:
 > What do you think if we combine -l, -q and -v parameters in the following way:
 > absence of the parameter will set log level to base (1)
 > -l off will work as it is right now (logging is off)
 > -l N is setup of the level (i.e., -l 1 will be equal to the default
 > settings, where N can be from 0 to 2 as it is right now).
 > 
 > This way we can simplify the log handling from source code point of
 > view. Having three parameters which might collide with each other
 > seems rather error prone.

Combining them might mean we can't express some existing use-cases though.
Verbosity of the messages to the screen vs what gets logged to disk are kind
of separate things.

Valid right now:

logging to disk, no output to screen other than seed. (-qq)
logging to disk, output seeds & watchdog progress counter (-q)
logging to disk, syscall details (no args)
logging to disk, verbose output (-v)

and 'no log' variants of all.
I'm not sure we can really express 8 possibilities into one arg and
without people needing to look up what the values represent.


	Dave

Re: Patch suggestion - logs cleanup

[Ildar Muslukhov]

got it, then lets keep it as is.

On Fri, Oct 4, 2013 at 1:05 PM, Dave Jones <davej@redhat.com> wrote:
> On Fri, Oct 04, 2013 at 12:34:35PM -0700, Ildar Muslukhov wrote:
>  > What do you think if we combine -l, -q and -v parameters in the following way:
>  > absence of the parameter will set log level to base (1)
>  > -l off will work as it is right now (logging is off)
>  > -l N is setup of the level (i.e., -l 1 will be equal to the default
>  > settings, where N can be from 0 to 2 as it is right now).
>  >
>  > This way we can simplify the log handling from source code point of
>  > view. Having three parameters which might collide with each other
>  > seems rather error prone.
>
> Combining them might mean we can't express some existing use-cases though.
> Verbosity of the messages to the screen vs what gets logged to disk are kind
> of separate things.
>
> Valid right now:
>
> logging to disk, no output to screen other than seed. (-qq)
> logging to disk, output seeds & watchdog progress counter (-q)
> logging to disk, syscall details (no args)
> logging to disk, verbose output (-v)
>
> and 'no log' variants of all.
> I'm not sure we can really express 8 possibilities into one arg and
> without people needing to look up what the values represent.
>
>
>         Dave
>