[PATCH 1/2] build: add backward compatibility for nested drivers

[Bruce Richardson]

On Tue, Sep 23, 2025 at 02:08:35PM +0100, Kevin Traynor wrote:
> On 22/09/2025 16:51, Thomas Monjalon wrote:
> > 22/09/2025 13:07, Kevin Traynor:
> >> --- a/drivers/meson.build
> >> +++ b/drivers/meson.build
> >> -# add cmdline disabled drivers and meson disabled drivers together
> >> -disable_drivers += ',' + get_option('disable_drivers')
> >> +# map legacy driver names
> >> +driver_map = {
> >> +    'net/e1000': 'net/intel/e1000',
> >> +    'net/fm10k': 'net/intel/fm10k',
> >> +    'net/i40e': 'net/intel/i40e',
> >> +    'net/iavf': 'net/intel/iavf',
> >> +    'net/ice': 'net/intel/ice',
> >> +    'net/idpf': 'net/intel/idpf',
> >> +    'net/ipn3ke': 'net/intel/ipn3ke',
> >> +    'net/ixgbe': 'net/intel/ixgbe',
> >> +    'net/cpfl': 'net/intel/cpfl',
> >> +}
> > 
> > Should we build this list inside a file drivers/net/intel/meson.build ?
> > I'm not sure my idea is better...
> > 
> 
> Not sure. It's generic as is, so any other driver moved anywhere could
> add to this list here easily. Let's see what others think.
> 

I'm fine either way. Having a general list may be good, as we may have
other driver moves or renames in future too.

> >> +
> >> +# add cmdline drivers
> >> +foreach driver_type : [['disable', get_option('disable_drivers')],
> >> +                       ['enable', get_option('enable_drivers')]]
> >> +    driver_list_name = driver_type[0] + '_drivers'
> >> +    cmdline_drivers = ',' + driver_type[1]
> >> +
> >> +    foreach driver : cmdline_drivers.split(',')
> >> +        if driver_map.has_key(driver)
> > 
> > I feel we need comments for above parsing.
> > 
> 
> Ack, will add
> 
> >> +            driver_mapped = driver_map[driver]
> >> +            warning('Driver name "@0@" is deprecated, please use "@1@" instead.'
> > 
> > Not sure about this warning.
> > We can keep compatibility without saying it is deprecated.
> > 
> 
> Yes, that is a good point for discussion. Seen as support for the legacy
> names were already dropped and I wasn't aware of any ABI like policy
> about it, I thought there may be a preference for deprecation
> warning/continuing to move to the new name only.
> 
> I would be happy to keep the legacy name without a warning/deprecation
> for a longer term and we could adopt this as general guideline by
> default too. It should not cost much effort to do this.
> 

Agreed. If we do decide after a while to remove an old name, then we should
do a deprecation notice first.

> Another minor point is, if this needs a Fixes tag? Yes, in the sense it
> feels like it added a banana skin for users (the patches are because I
> hit this issue with 25.07). I didn't add it for now, as no guarantees
> were broken and there isn't an upstream stable for backporting to anyway.
> 

If there is no backporting, I'm not sure it matters. Maybe add one anyway
to imply that this was something that should have been thought of in the
original patch.

/Bruce