netdev - Re: [PATCH net-next RFC 1/3] faux: extend the creation function for module namespace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6exs3p35dz6e5mydwvchw67gymewpzp5qyikftl2mvdvhp3hqf@saz6uetgya3l>
Date: Tue, 18 Mar 2025 16:26:05 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com, 
	kuba@...nel.org, pabeni@...hat.com, saeedm@...dia.com, leon@...nel.org, 
	tariqt@...dia.com, andrew+netdev@...n.ch, dakr@...nel.org, rafael@...nel.org, 
	przemyslaw.kitszel@...el.com, anthony.l.nguyen@...el.com, cratiu@...dia.com, 
	jacob.e.keller@...el.com, konrad.knitter@...el.com, cjubran@...dia.com
Subject: Re: [PATCH net-next RFC 1/3] faux: extend the creation function for
 module namespace

Tue, Mar 18, 2025 at 03:36:34PM +0100, gregkh@...uxfoundation.org wrote:
>On Tue, Mar 18, 2025 at 01:47:04PM +0100, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@...dia.com>
>> 
>> It is hard for the faux user to avoid potential name conflicts, as it is
>> only in control of faux devices it creates. Therefore extend the faux
>> device creation function by module parameter, embed the module name into
>> the device name in format "modulename_permodulename" and allow module to
>> control it's namespace.
>
>Do you have an example of how this will change the current names we have
>in the system to this new way?  What is going to break if those names
>change?

I was under impression, that since there are no in-tree users of faux
yet (at least I don't see them in net-next tree), there is no breakage.

>
>I say this as the perf devices seem to have "issues" with their names
>and locations in sysfs as userspace tools use them today, and in a
>straight port to faux it is ok, but if the device name changes, that is
>going to have problems.

Got it. I didn't consider that.


>
>Why can't you handle this "namespace" issue yourself in the caller to
>the api?  Why must the faux code handle it for you?  We don't do this
>for platform devices, why is this any different?

Well, I wanted to avoid alloc&printf names in driver, since
dev_set_name() accepts vararg and faux_device_create()/faux_device_create_with_groups()
don't.

Perhaps "const char *name" could be formatted as well for
faux_device_create()/faux_device_create_with_groups(). My laziness
wanted to avoid that :) Would that make sense to you?

>
>thanks,
>
>greg k-h