Re: [net-next PATCH 00/15] eth: fbnic: Add network driver for Meta Platforms Host Network Interface

[Jacob Keller <jacob.e.keller@intel.com>]

On 4/10/2024 11:31 PM, Jiri Pirko wrote:
> Thu, Apr 11, 2024 at 12:03:54AM CEST, jacob.e.keller@intel.com wrote:
>>
>>
>> On 4/10/2024 12:58 PM, Jakub Kicinski wrote:
>>> On Wed, 10 Apr 2024 11:29:57 -0700 Florian Fainelli wrote:
>>>>> If we are going to be trying to come up with some special status maybe
>>>>> it makes sense to have some status in the MAINTAINERS file that would
>>>>> indicate that this driver is exclusive to some organization and not
>>>>> publicly available so any maintenance would have to be proprietary.  
>>>>
>>>> I like that idea.
>>>
>>> +1, also first idea that came to mind but I was too afraid 
>>> of bike shedding to mention it :) Fingers crossed? :)
>>>
>>
>> +1, I think putting it in MAINTAINERS makes a lot of sense.
> 
> Well, how exactly you imagine to do this? I have no problem using
> MAINTAINERS for this, I was thinking about that too, but I could not
> figure out the way it would work. Having driver directory is much more
> obvious, person cooking up a patch sees that immediatelly. Do you look
> at MAINTAINTERS file when you do some driver API changing patch/ any
> patch? I certainly don't (not counting get_maintainers sctipt).

I use MAINTAINERS (along with get_maintainers) to figure out who to CC
when dealing with a driver. I guess I probably don't do so before making
a change.

I guess it depends on what the intent of documenting it is for.
Presumably it would be a hint and reminder to future maintainers that if
the folks listed as MAINTAINERS are no longer responsive then this
driver can be reverted.

Or if you push more strongly towards "its up to them to do all
maintenance" i.e. we don't make API changes for them, etc? I didn't get
the sense that was the consensus.

The consensus I got from reading this thread is that most people are ok
with merging the driver. Some reservations about the future and any API
changes specifically for the one driver... Some reservations about the
extra maintenance burden.

Several others pointed out example cases which are similar in
availability. Perhaps not quite as obvious as the case of this where the
device is produced and consumed by the same group only.

The practical reality is that many of the devices are practically
exclusive if not definitionally so.