Re: [PATCH v5 0/9] Fixes for early logging/prints and related cleanups

[Stefano Brivio <sbrivio@redhat.com>]

On Fri, 21 Jun 2024 11:17:34 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Thu, Jun 20, 2024 at 06:15:09PM +0200, Stefano Brivio wrote:
> > The most apparent issue fixed by this series is the one from 4/6: with
> > a log file configured, we wouldn't print to standard error anymore,
> > during initialisation, which means that users such as libvirt lost
> > the ability to report meaningful error messages that occurred during
> > initialisation, in that case.
> > 
> > v5:
> > - in 4/8, rename the new flag once more to 'log_runtime': we don't
> >   want to log to standard error if we're running in foreground, a
> >   log file is given, and initialisation is done, otherwise debugging
> >   pasta when it spawns its own shell becomes rather impractical  
> 
> Ah.. right.  See, I still think the semantics of always printing to
> stderr when foreground make more sense, but I guess I do see the point
> that having pasta messages appear in your pasta-spawned shell is ugly.
> 
> My preferred approach for that would to keep the basic semantics that
> we always log to stderr when foreground, but when we're spawning a
> pasta shell we default to 'quiet' log level.  That way if you really
> do want messages to stderr along with your shell/command (which I
> sometimes do), you can get that by using --debug or whatever.

That's already the default, see pasta_start_ns():

	if (!c->debug)
		c->quiet = 1;

the problem is that if you want to debug something, and use a pasta
shell (which is the most indicated way to debug something in most
cases, I would say), you would usually pass --debug and a log file.

Before and after this series (v5, but not v4), if you pass a log file,
that debug output stays in the log file.

If you don't give a log file, debug information will printed to stderr
as usual.

-- 
Stefano