Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Matthew Wood]

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

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Andreas Hindborg]

"Matthew Wood" <thepacketgeek@gmail.com> writes:

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

Thanks, I appreciate it.

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

How about using default groups for this, would that not be feasible?

While I understand the use case for this patch, I don't think it is a
good solution. It changes the fundamental assumptions of configfs. So if
we are going to go down this route I would like more people to review
the patches and weigh in with their opinion.

Perhaps we should discuss this at a venue where we can get some more
people together? LPC or LSF maybe?


Best regards,
Andreas Hindborg

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Breno Leitao]

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.

Thanks
--breno

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Joel Becker]

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@10.0.0.1/eth1,9353@10.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@evilplan.org

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Andreas Hindborg]

Breno Leitao <leitao@debian.org> writes:

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

I'd appreciate if we can get some people in a room and force them to
think about this. I think it is a good idea if you submit a topic. If we
don't get a slot, we can see what we can do in the hallway, and if that
does not work out we are forced to make a decision between the 4 of us
participating on list. At least nobody can say we did not try to collect
input and opinions then.


Best regards,
Andreas Hindborg

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Breno Leitao]

On Wed, Feb 11, 2026 at 08:53:12AM +0100, Andreas Hindborg wrote:
> Breno Leitao <leitao@debian.org> writes:
> 
> > 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.
> 
> I'd appreciate if we can get some people in a room and force them to
> think about this. I think it is a good idea if you submit a topic. If we
> don't get a slot, we can see what we can do in the hallway, and if that
> does not work out we are forced to make a decision between the 4 of us
> participating on list. At least nobody can say we did not try to collect
> input and opinions then.

That is an excellent follow-up and direction, let me submit a topic in there.

--breno

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Andreas Hindborg]

Hi Breno,

Breno Leitao <leitao@debian.org> writes:

> On Wed, Feb 11, 2026 at 08:53:12AM +0100, Andreas Hindborg wrote:
>> Breno Leitao <leitao@debian.org> writes:
>> 
>> > 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.
>> 
>> I'd appreciate if we can get some people in a room and force them to
>> think about this. I think it is a good idea if you submit a topic. If we
>> don't get a slot, we can see what we can do in the hallway, and if that
>> does not work out we are forced to make a decision between the 4 of us
>> participating on list. At least nobody can say we did not try to collect
>> input and opinions then.
>
> That is an excellent follow-up and direction, let me submit a topic in there.

I did not see a topic on list, did you submit?

At any rate, I did not receive an invitation for LSF this year, so I
will not be able to meet up in that venue.


Best regards,
Andreas Hindborg

Re: [PATCH RFC 0/2] configfs: enable kernel-space item registration

[Breno Leitao]

Hello Andreas,

On Fri, Mar 20, 2026 at 12:29:58PM +0100, Andreas Hindborg wrote:
>
> Hi Breno,
>
> Breno Leitao <leitao@debian.org> writes:
>
> > On Wed, Feb 11, 2026 at 08:53:12AM +0100, Andreas Hindborg wrote:
> >> Breno Leitao <leitao@debian.org> writes:
> >>
> >> > 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.
> >>
> >> I'd appreciate if we can get some people in a room and force them to
> >> think about this. I think it is a good idea if you submit a topic. If we
> >> don't get a slot, we can see what we can do in the hallway, and if that
> >> does not work out we are forced to make a decision between the 4 of us
> >> participating on list. At least nobody can say we did not try to collect
> >> input and opinions then.
> >
> > That is an excellent follow-up and direction, let me submit a topic in there.
>
> I did not see a topic on list, did you submit?

Unfortunately, I haven't submitted a topic and won't be able to attend.
My daughter is due around the same time as the conference, and I didn't
realize the conflict until recently. :-|

> At any rate, I did not receive an invitation for LSF this year, so I
> will not be able to meet up in that venue.

Perhaps it would be best to continue the discussion on the mailing list?