Message-ID: <aYTWbElo_U_neJZi@deathstar>
Date: Thu, 5 Feb 2026 09:46:52 -0800
From: Matthew Wood <thepacketgeek@...il.com>
To: Andreas Hindborg <a.hindborg@...nel.org>, 
	Breno Leitao <leitao@...ian.org>
Cc: 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, jlbec@...lplan.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

Hi Breno and Andreas,

I'm in favor of this RFC as I think the current flow of needing to
create the cmdline0 dir in the netconsole configfs (when DYNAMIC config
is enabled) prior to modifying the values is not ideal.

I think there are good points shared about sysfs vs. configfs being used
for the cmdline target modification and wanted to add my thoughts.

On Fri, Dec 05, 2025 at 08:29:04PM +0100, Andreas Hindborg wrote:
> "Breno Leitao" <leitao@...ian.org> writes:
> 
> > Hello Andreas,
> >
> > On Fri, Dec 05, 2025 at 06:35:12PM +0100, Andreas Hindborg wrote:
> >> "Breno Leitao" <leitao@...ian.org> writes:
> >>
> >> > This series introduces a new kernel-space item registration API for configfs
> >> > to enable subsystems to programmatically create configfs items whose lifecycle
> >> > is controlled by the kernel rather than userspace.
> >> >
> >> > Currently, configfs items can only be created via userspace mkdir operations,
> >> > which limits their utility for kernel-driven configuration scenarios such as
> >> > boot parameters or hardware auto-detection.
> >>
> >> I thought sysfs would handle this kind of scenarios?
> >
> > sysfs has gaps as well, to manage user-create items.
> >
> > Netconsole has two types of "targets". Those created dynamically
> > (CONFIG_NETCONSOLE_DYNAMIC), where user can create and remove as many
> > targets as it needs, and netconsole would send to it. This fits very
> > well in configfs.
> >
> >   mkdir /sys/kernel/config/netconsole/mytarget
> >   .. manage the target using configfs items/files
> >   rmdir /sys/kernel/config/netconsole/mytarget
> >
> > This is a perfect fit for configfs, and I don't see how it would work
> > with sysfs.
> 
> Right, these go in configfs, we are on the same page about that.
> 
> >
> > On top of that, there are netconsole targets that are coming from
> > cmdline (basically to cover while userspace is not initialized). These
> > are coming from cmdline and its life-cycle is managed by the kernel.
> > I.e, the kernel knows about them, and wants to expose it to the user
> > (which can even disable them later). This is the problem I this patch
> > addresses (exposing them easily).
> 
> I wonder if these entries could be exposed via sysfs? You could create
> the same directory structure as you have in configfs for the user
> created devices, so the only thing user space has to do is to point at a
> different directory.
> 
Although technically feasible, this approach leads to an inconsistent
and confusing management of the netconsole targets. A configfs path for
user-space created targets and a sysfs path for the cmdline initiated
target that can also be modified from userspace (e.g. to update
remote_ip or userdata fields).

I think Breno's approach sets up for the most intuitive user experience.
The cmdline config for netconsole is also user-provided, so it seems
like it should behave as a pre-populated configfs target that happens to
pass from cmdline through netconsole module init to the current configfs
interface. The initial values are not determined by the kernel itself.

> 
> Best regards,
> Andreas Hindborg
> 
> 
> 

Powered by blists - more mailing lists