[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZDrb58HEqLvG6ZoQ@sashalap>
Date: Sat, 15 Apr 2023 13:16:23 -0400
From: Sasha Levin <sashal@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: "Samudrala, Sridhar" <sridhar.samudrala@...el.com>,
Willem de Bruijn <willemdebruijn.kernel@...il.com>,
Pavan Kumar Linga <pavan.kumar.linga@...el.com>,
willemb@...gle.com, decot@...gle.com, netdev@...r.kernel.org,
jesse.brandeburg@...el.com, edumazet@...gle.com,
intel-wired-lan@...ts.osuosl.org, anthony.l.nguyen@...el.com,
pabeni@...hat.com, davem@...emloft.net
Subject: Re: [Intel-wired-lan] [PATCH net-next v2 00/15] Introduce Intel IDPF
driver
On Fri, Apr 14, 2023 at 03:27:44PM -0700, Jakub Kicinski wrote:
>On Fri, 14 Apr 2023 18:01:42 -0400 Sasha Levin wrote:
>>> As I said previously in [0] until there is a compatible, widely
>>> available implementation from a second vendor - this is an Intel
>>> driver and nothing more. It's not moving anywhere.
>>
>> My concern isn't around the OASIS legal stuff, it's about the users who
>> end up using this and will end up getting confused when we have two (or
>> more) in-kernel "IDPF" drivers.
>>
>> I don't think that moving is an option - it'll brake distros and upset
>> users: we can't rename drivers as we go because it has a good chance of
>> breaking users.
>
>Minor pain for backports but I don't think we need to rename anything,
>just move.
>
>Or we can just leave it be under intel/, since there are not other
>participant now. Unless perhaps under google/ is a better option?
>
>Drivers are organized by the vendor for better or worse. We have a
>number of drivers under the "wrong directly" already. Companies merge /
>buy each others product lines, there's also some confusion about common
>IP drivers. It's all fine, whatever.
>
>Users are very, very unlikely to care.
>
>>> I think that's a reasonable position which should allow Intel to ship
>>> your code and me to remain professional.
>>
>> No concerns about OASIS or the current code, I just don't want to make
>> this a mess for the users.
>
>It's not a standard until someone else actually adopts it. What stops
>all the other vendors from declaring that their driver interface is a
>standard now, too?
>
>We have a long standing rule in netdev against using marketing language.
Sorry, I may not have explained myself well. My concern is not around
what's standard and what's not, nor around where in the kernel tree
these drivers live.
I'm concerned that down the road we may end up with two drivers that
have the same name, and are working with hardware so similar that it
might be confusing to understand which driver a user should be using.
Yes, it's not something too big, but we have an opportunity to think
about this before committing to anything that might be a pain down the
road.
--
Thanks,
Sasha
Powered by blists - more mailing lists