From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124])
by passt.top (Postfix) with ESMTP id B611C5A004F
for <passt-dev@passt.top>; Mon, 24 Jun 2024 11:46:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
s=mimecast20190719; t=1719222374;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references;
bh=4nzWnBgyLFPxtCQ6bvHAatESGzHzilXAYXIQV8xlrpQ=;
b=fliXHsFRUoklnQOZR3M9Hw8ptAFLqgxPCU9jj9bY1azvc7W30aUe9U5ncj9nVP/ZgPBcpW
LPmIcuVZas8crDudsXSXW3CMkppQPM6dt+ChTFThkTYduZqEUNFuG9b+5TyHgz4qIgzVmu
NFp3goNYtGw2bmT9Gql+chHJFN7a3rc=
Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com
[209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS
(version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id
us-mta-614-wjvHa9ATMOupyNuINjvZag-1; Mon, 24 Jun 2024 05:46:10 -0400
X-MC-Unique: wjvHa9ATMOupyNuINjvZag-1
Received: by mail-qv1-f70.google.com with SMTP id 6a1803df08f44-6b4fdcf92d9so68417396d6.3
for <passt-dev@passt.top>; Mon, 24 Jun 2024 02:46:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1719222370; x=1719827170;
h=content-transfer-encoding:mime-version:organization:references
:in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=4nzWnBgyLFPxtCQ6bvHAatESGzHzilXAYXIQV8xlrpQ=;
b=SSB35GUVspTskyC3Kwp9PhJyqwrgOOVilYcQs9FTPy7KH4SlurhP/H1H0OgmJ0Qhob
JsHweRuxEjhusXjiKbkfL+CgQdOyWC18DsZQp8CHQm3IV4b1kLPNwAPF2EO2yOs/UBXm
0XzRgHkLIMDiSOcItaxFAirYOTxLHugIECTSfPeItrNMICa8FfLn5YbU7oD+PNLn6/DD
m2Tm7ygSYYy52QvX1SexbPIfehI2zwDx12U11unjw1ZafuiH7dC7R0M8tjGmcK33CvWz
jPPYYNydMfb92eDT94dOsM5vAzgo4nUYkykFIoBaEzveLMeFQSI+aerk4gd2fBZ0FNBA
BRNw==
X-Gm-Message-State: AOJu0YwNDRssIGOdnYgJW7mH6WtAWEE8T2pnNX+hxjXLF4c+Rm6XwoCM
6vN8kJJDjMK10U6TuoBYKm+zX9C5xA8BF+8Q8XtPS1rAEWeWY+eViaD2wwB2rqN7oqvJ4PWMAzN
aS9mgGC37PpMOBMK1dPiqnGP0QyYgTgCXCKxJf9fAhaL9b8FiCA==
X-Received: by 2002:ad4:5fc9:0:b0:6b5:4435:fe4d with SMTP id 6a1803df08f44-6b544360a5bmr50406966d6.38.1719222369643;
Mon, 24 Jun 2024 02:46:09 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IErNR2w8urBzwMlyJtL0RH8/u+0rbArZ44colmcfTD/F+vcRAk+tSIIrgjQ69UydZo/0g9SHw==
X-Received: by 2002:ad4:5fc9:0:b0:6b5:4435:fe4d with SMTP id 6a1803df08f44-6b544360a5bmr50406756d6.38.1719222369172;
Mon, 24 Jun 2024 02:46:09 -0700 (PDT)
Received: from maya.cloud.tilaa.com (maya.cloud.tilaa.com. [164.138.29.33])
by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6b5477ee57csm11566826d6.75.2024.06.24.02.46.07
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Mon, 24 Jun 2024 02:46:07 -0700 (PDT)
Date: Mon, 24 Jun 2024 11:45:32 +0200
From: Stefano Brivio <sbrivio@redhat.com>
To: David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH v5 0/9] Fixes for early logging/prints and related
cleanups
Message-ID: <20240624114521.45638044@elisabeth>
In-Reply-To: <ZnkE5HqqvTmDrOyw@zatzit>
References: <20240620161518.142285-1-sbrivio@redhat.com>
<ZnTUrhu8LNWi-krS@zatzit>
<20240621113348.246d9564@elisabeth>
<ZnkE5HqqvTmDrOyw@zatzit>
Organization: Red Hat
X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu)
MIME-Version: 1.0
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Message-ID-Hash: CLVSTUK7AT5FDFYOB7Z2TD732WMJG2KB
X-Message-ID-Hash: CLVSTUK7AT5FDFYOB7Z2TD732WMJG2KB
X-MailFrom: sbrivio@redhat.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: passt-dev@passt.top, Yalan Zhang <yalzhang@redhat.com>
X-Mailman-Version: 3.3.8
Precedence: list
List-Id: Development discussion and patches for passt <passt-dev.passt.top>
Archived-At: <https://archives.passt.top/passt-dev/20240624114521.45638044@elisabeth/>
Archived-At: <https://passt.top/hyperkitty/list/passt-dev@passt.top/message/CLVSTUK7AT5FDFYOB7Z2TD732WMJG2KB/>
List-Archive: <https://archives.passt.top/passt-dev/>
List-Archive: <https://passt.top/hyperkitty/list/passt-dev@passt.top/>
List-Help: <mailto:passt-dev-request@passt.top?subject=help>
List-Owner: <mailto:passt-dev-owner@passt.top>
List-Post: <mailto:passt-dev@passt.top>
List-Subscribe: <mailto:passt-dev-join@passt.top>
List-Unsubscribe: <mailto:passt-dev-leave@passt.top>
On Mon, 24 Jun 2024 15:32:20 +1000
David Gibson <david@gibson.dropbear.id.au> wrote:
> On Fri, Jun 21, 2024 at 11:33:55AM +0200, Stefano Brivio wrote:
> > 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.
>
> Oh... good point.
>
> > 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.
>
> I understand the choice in the short term, but this still doesn't feel
> quite right to me.
>
> I'm wondering if we should treat spawning a a pasta command as though
> we're going into the background. It's not in the Unix technical
> sense, but it is going to the background in the loose sense that pasta
> is no longer the thing that the user is primarily looking at on this
> terminal.
>
> But then, it would be nice to have a way to force output to stderr
> even with a pasta command - I find that pretty useful when debugging a
> specific problem, particularly when using a specific command rather
> than a shell. Maybe we could allow "-l -" or "-l stderr" or something
> with a special meaning?
But that's already the case if you give --debug (or --trace) but no log
file, isn't that enough?
--
Stefano