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

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Mar 18, 2025 at 04:26:05PM +0100, Jiri Pirko wrote:
> Tue, Mar 18, 2025 at 03:36:34PM +0100, gregkh@linuxfoundation.org wrote:
> >On Tue, Mar 18, 2025 at 01:47:04PM +0100, Jiri Pirko wrote:
> >> From: Jiri Pirko <jiri@nvidia.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