From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id DEE405A004F for ; Mon, 24 Jun 2024 07:32:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202312; t=1719207144; bh=dtZva9xczZ2Bqry1Kyco+Mg3ADKPpsUCVqxpUAJXjYI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Suhk+uDKtJX/VVUdD5nqbnmQOvsI2+pCjXVwlU81QgGXo/9V/7u3QNMd/ivKAcucg PG5OvOV7LiULbjGvkcnl5LKj5FpZ1tdF6jHqerAxHd+m/vrcXDB1+sVgRFfuFJpjVY prO9kR1+2riVNDNIV/PIJubdRQCK3iY70Ar6KHBHQ2sv8Sws2kV6nUfwh91zVh66st dAq+O+nIgx7Cs1eyOkriOr+MUHBo8Tsy8zQxM0+DLREsGL+oY7N30fqnggz4vtHvIb Bg41zWETrTx2nKtL1d9NSsss94tELHgwMHutvNBULJ9zDXDfg+EsWxuY4reU2zbHOo vtezb2mjgpFuw== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4W6xRr68Vrz4wbr; Mon, 24 Jun 2024 15:32:24 +1000 (AEST) Date: Mon, 24 Jun 2024 15:32:20 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v5 0/9] Fixes for early logging/prints and related cleanups Message-ID: References: <20240620161518.142285-1-sbrivio@redhat.com> <20240621113348.246d9564@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="MUtep9uw6xTfY6SK" Content-Disposition: inline In-Reply-To: <20240621113348.246d9564@elisabeth> Message-ID-Hash: I6NPEFZ4LYISGI4HS4MIP3CAKIOVLOHT X-Message-ID-Hash: I6NPEFZ4LYISGI4HS4MIP3CAKIOVLOHT X-MailFrom: dgibson@gandalf.ozlabs.org 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 X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --MUtep9uw6xTfY6SK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 21, 2024 at 11:33:55AM +0200, Stefano Brivio wrote: > On Fri, 21 Jun 2024 11:17:34 +1000 > David Gibson wrote: >=20 > > 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. > > >=20 > > > 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 =20 > >=20 > > 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. > >=20 > > 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. >=20 > That's already the default, see pasta_start_ns(): >=20 > if (!c->debug) > c->quiet =3D 1; >=20 > 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. >=20 > 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? --=20 David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson --MUtep9uw6xTfY6SK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmZ5BOMACgkQzQJF27ox 2Gf6EA/+LDU4+dAcFewD/MMISnQWsF4Uji8oUMRmbuKdcqJnSHvdrgW2bB6t7zEm zpJKlMt3A2qtGM3YTy3akcTJhHO74kIUW+hZLlNFHEoOy+Ql8q0i7HCVpgVTfrkY 9kandlIYhpnm1oP/vEVR2Hes7hG0YXEeFjbXJ/TTJjFfRv5+YtjcTLKVjRagK4Ky Apt+iEq/hX9A5i+S1qvOZXAXF2UfkrHwWHvCwGcPGrEaLC6+3KYPu8LnwAEE4USd Y03eumwVcxkhzful+NFiK6cmZJUJuCe8u6vuqeWIUIELzwF36qtpQ377Bx7ES5gL LVCHi4l00qoXP/tBrXypFnSQoD21W3BT3b5l8x+Y3dWP/HMFCCQrx9qx+Xlf11vd jjgrNnkDoQC33dgUXxeKa0gZonCgvQtE7oM4OthQpcvTrDmJd5RKkhUtgquZILv1 6l7YmxHtkfGPPmehKkJPjukn+YASHk4UCG9qPbH8OhNKuOr7uRe78Mw49LkGfnxk FvNaRk0YS7/ba87Gga/H/SYoYy2/2sItf3/pOTCjThg6oa9YbA9S4BGezbsj7Yuu 3B2qLeeK6h0Z5wGcX5pCv6NmXsqd5OBkmlivhx+5M/luqJSrmmddeguR0Bfl5Nau hzhbcHerWVASJKVHNYLDxGiDJI7UPg1yR2FIxB8e8Bdel2doLfM= =mH8z -----END PGP SIGNATURE----- --MUtep9uw6xTfY6SK--