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.

This discussion about this feature started 2 years ago[1], when netconsole needed to have
an configfs target that maps to what was passed by cmdline (something as
netconsole=+6666@192.168.1.1....)

The suggestion was to workaround configfs limitation by asking users to create
some pre-defined configfs entries specially named (such as "cmdlineX", where X
is the entry index in the list of targets), that would match entries coming from
cmdline.

That proved to be confusing in many ways, such as:

 1) if cmdline is not properly passed or parsed, then cmdline0 becomes a new
    and unrelated target
 2) If netconsole becomes a module, then cmdline0 is not populated, so, the
    creation of cmdline0 is something unrelated to what we have in cmdline.
 3) The admin needs to create X items properly matching the iterms from cmdline,
    which is error prone.

The solution proposed in this patchset is to manage the life cycle of an item by the
kernel (if the cmdline entry exists, it will populate the cofingfs
automatically), instead of by the user (mkdir-ing special names).

The new configfs_register_item() and configfs_unregister_item() functions fill
this gap by allowing kernel modules to register items that appear in configfs
but are protected from userspace removal. These items are marked with the
CONFIGFS_USET_DEFAULT flag, making them behave similarly to default groups that
are automatically created but cannot be removed via rmdir.

The primary motivation for this work is to support dynamic netconsole target
registration from boot parameters.

Currently, netconsole can be configured either statically at boot time
(cmdline) or dynamically via userspace manipulation of configfs directories.

However, there is no way to create netconsole targets from kernel command line
parameters that persist in configfs for runtime inspection and modification.

This series addresses that limitation by providing the necessary configfs
infrastructure, making netconsole management easier, and simplifying the
code.

Link: https://lore.kernel.org/all/ZRWRal5bW93px4km@gmail.com/ [1]

---
Breno Leitao (2):
      configfs: add kernel-space item registration API
      netconsole: Plug to dynamic configfs item

 drivers/net/netconsole.c |  63 +++++++++++++++-----------------------------
 fs/configfs/dir.c        | 134 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/configfs.h |   4 +++
 3 files changed, 159 insertions(+), 42 deletions(-)
---
base-commit: e538109ac71d801d26776af5f3c54f548296c29c
change-id: 20251128-configfs_netcon-f53ec4ca3363

Best regards,
--  
Breno Leitao <leitao@debian.org>

"Breno Leitao" <leitao@debian.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?


Best regards,
Andreas Hindborg

Hello Andreas,

On Fri, Dec 05, 2025 at 06:35:12PM +0100, Andreas Hindborg wrote:
> "Breno Leitao" <leitao@debian.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.

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).

It is kind of a mix of kernel and user-managed configuration items in
coexisting.

"Breno Leitao" <leitao@debian.org> writes:

> Hello Andreas,
>
> On Fri, Dec 05, 2025 at 06:35:12PM +0100, Andreas Hindborg wrote:
>> "Breno Leitao" <leitao@debian.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.


Best regards,
Andreas Hindborg

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@debian.org> writes:
> 
> > Hello Andreas,
> >
> > On Fri, Dec 05, 2025 at 06:35:12PM +0100, Andreas Hindborg wrote:
> >> "Breno Leitao" <leitao@debian.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
> 
> 
>