[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aYqDEW1sSnaq26GK@google.com>
Date: Mon, 9 Feb 2026 17:00:01 -0800
From: Joel Becker <jlbec@...lplan.org>
To: Breno Leitao <leitao@...ian.org>
Cc: Andreas Hindborg <a.hindborg@...nel.org>,
Matthew Wood <thepacketgeek@...il.com>,
Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
linux-kernel@...r.kernel.org, hch@...radead.org,
linux-fsdevel@...r.kernel.org, netdev@...r.kernel.org,
gustavold@...il.com, asantostc@...il.com, calvin@...nvd.org,
kernel-team@...a.com
Subject: Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration
On Mon, Feb 09, 2026 at 05:56:34AM -0800, Breno Leitao wrote:
> On Mon, Feb 09, 2026 at 11:58:22AM +0100, Andreas Hindborg wrote:
> > Perhaps we should discuss this at a venue where we can get some more
> > people together? LPC or LSF maybe?
>
> Certainly, I agree. I’ve submitted my subscription to LSFMMBPF with the main
> goal to discuss this topic. I wasn’t planning to present it this, given it was
> a "overkill"?, but I’m happy to do so if that is the right direction.
Sadly, I won't be able to make LSF or similar. I do have strong
opinions on this (you can find previous threads where Breno and I
discussed the topic).
I think the usability issue is real. It's worth talking about how to
close the experience gap. But like Andreas, I also have a strong
concern about changing the fundamental paradigm of configfs. Open it up
to solve this one "can't do it any other way" case, and watch all the
"we can do it with userspace, but it's simpler to just code it with this
kernel hook" followers appear.
Since the problem is entirely about pre-userspace timing, perhaps that's
where we can focus? Could this be done in initfs? I suspect for
netconsole that initfs is too late; command line arguments are
necessary. What about, rather than create a generic "kernelspace API
for configfs item creation" could we just write a "command line
arguments that represent what a userspace mkdir would do" hook? This
could be private to configfs, and maybe even limited to when in the
kernel startup it can be used.
I can imagine a netconsole argument like:
linux netconsole=4444@...0.0.1/eth1,9353@...0.0.2
could become a general form like:
linux configfs=netconsole/newtarget:local_port=4444&local_ip=10.0.0.1&dev_name=eth1&remote_port=9353&remote_ip=10.0.0.2
A legacy driver like netconsole could even take its legacy string and
convert it to the configfs form and pass it along, as long as its within
the module_init/boot scope.
Just a thought. I haven't evaluated the practicalities.
--
"War doesn't determine who's right; war determines who's left."
http://www.jlbec.org/
jlbec@...lplan.org
Powered by blists - more mailing lists