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-stench-astound-7181@gregkh>
Date: Tue, 18 Mar 2025 18:27:17 +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 05:51:34PM +0100, Jiri Pirko wrote:
> Tue, Mar 18, 2025 at 05:04:37PM +0100, gregkh@...uxfoundation.org wrote:
> >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.
> 
> Sure, but it's still next. Next might break (uapi) as long it's next,
> right?

The point is that these conversions are thinking that their name is
stable.  This change is going to mean that those patches that have been
accepted into different trees are going to change.

> >> 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?
> 
> Why should I care about rust? I got the impression the deal is that
> rust bindings are taken care of by rust people. Did that change and
> we need to keep rust in mind for all internal API? That sounds scarry
> to me :(

I was just asking if you knew, that's all.

thanks,

greg k-h