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 for Android: free password hash cracker in your pocket

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

Message-ID: <paftiyrmjuiirv7j26eenezpqlszva55w2lmsutflmt2tfwufp@za2pg2q7t43n>
Date: Tue, 18 Mar 2025 17:51:34 +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 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?


>
>> >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 :)

Yeah, I don't really want to do anything complex, that's why I wanted to
take leverage of dev_set_name()


>
>> 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 :(


>
>thanks,
>
>greg k-h