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 ; 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 ; 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 To: David Gibson Subject: Re: [PATCH v5 0/9] Fixes for early logging/prints and related cleanups Message-ID: <20240624114521.45638044@elisabeth> In-Reply-To: References: <20240620161518.142285-1-sbrivio@redhat.com> <20240621113348.246d9564@elisabeth> 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 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: On Mon, 24 Jun 2024 15:32:20 +1000 David Gibson 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 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