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: <2025031817-charter-respect-1483@gregkh>
Date: Tue, 18 Mar 2025 17:04:37 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Jiri Pirko <jiri@...nulli.us>
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

On Tue, Mar 18, 2025 at 04:26:05PM +0100, Jiri Pirko wrote:
> 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.

Look at linux-next please.

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

If you want to do something complex, do it in your driver :)

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

I wouldn't object to that, making it a vararg?  How would the rust
binding handle that?

thanks,

greg k-h