[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4f6598e12127cc6e80af7dde5149220d92b07b11.camel@themaw.net>
Date: Wed, 29 Apr 2020 10:53:00 +0800
From: Ian Kent <raven@...maw.net>
To: Lukas Czerner <lczerner@...hat.com>,
Christoph Hellwig <hch@...radead.org>
Cc: linux-ext4@...r.kernel.org, dhowells@...hat.com,
viro@...iv.linux.org.uk
Subject: Re: [PATCH v2 05/17] ext4: Allow sb to be NULL in ext4_msg()
On Tue, 2020-04-28 at 18:57 +0200, Lukas Czerner wrote:
> On Tue, Apr 28, 2020 at 09:48:08AM -0700, Christoph Hellwig wrote:
> > On Tue, Apr 28, 2020 at 06:45:24PM +0200, Lukas Czerner wrote:
> > > At the parsing phase of mount in the new mount api sb will not be
> > > available so allow sb to be NULL in ext4_msg and use that in
> > > handle_mount_opt().
> > >
> > > Also change return value to appropriate -EINVAL where needed.
> >
> > Shouldn't mount-time messages be reported using the logfc and
> > family
> > helpers from include/linux/fs_context.h? (which btw, have really
> > horrible over-generic names).
>
> I am sure it should at some point, but I am not really sure how ready
> it is at the moment. Last time I checked David told me not to bother
> using it yet.
>
> Is it ready yet David ? Should we be switching to it ?
The mount-API log macros tend to cause user confusion because they
often lead to unexpected log messages.
We're seeing that now with bugs logged due to unexpected messages
resulting from the NFS mount-API conversion.
I'd recommend mostly avoiding using the macros until there's been
time to reconsider how they should work, after all fsopen() and
friends will still get errno errors just not the passed string
description.
Ian
Powered by blists - more mailing lists