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: <gv6fmiz6orhrwpvbnlrlkikgwwzhq2u5icdwacfpivlmx6c3mc@dxg56wedutse>
Date: Wed, 19 Mar 2025 12:42:32 +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 06:27:17PM +0100, gregkh@...uxfoundation.org wrote:
>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.

Correct. I was under impression this could be handled in within "next".
If not, my bad.


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

Okay, I misunderstood. I have near 0 knowledge of Rust :)


>
>thanks,
>
>greg k-h