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

[Andreas Hindborg]

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