Fri, Apr 05, 2024 at 09:11:19AM CEST, pabeni@xxxxxxxxxx wrote: >On Thu, 2024-04-04 at 17:11 -0700, Alexander Duyck wrote: >> Again, I would say we look at the blast radius. That is how we should >> be measuring any change. At this point the driver is self contained >> into /drivers/net/ethernet/meta/fbnic/. It isn't exporting anything >> outside that directory, and it can be switched off via Kconfig. > >I personally think this is the most relevant point. This is just a new >NIC driver, completely self-encapsulated. I quickly glanced over the What do you mean by "self contained/encapsulated"? You are not using any API outside the driver? Every driver API change that this NIC is going to use is a burden. I did my share of changes like that in the past so I have pretty good notion how painful it often is. >code and it looks like it's not doing anything obviously bad. It really >looks like an usual, legit, NIC driver. > >I don't think the fact that the NIC itself is hard to grasp for anyone Distinguish "hard"/"impossible". >outside <organization> makes a difference. Long time ago Greg noted >that drivers has been merged for H/W known to have a _single_ existing >instance (IIRC, I can't find the reference on top of my head, but back >then was quite popular, I hope some other old guy could remember). > >To me, the maintainership burden is on Meta: Alex/Meta will have to >handle bug report, breakages, user-complains (I guess this last would >be the easier part ;). If he/they will not cope with the process we can >simply revert the driver. I would be quite surprised if such situation >should happen, but the impact from my PoV looks minimal. > >TL;DR: I don't see any good reason to not accept this - unless my quick >glance was too quick and very wrong, but it looks like other has >similar view. Do you actually see any good reason to accept this? I mean, really, could you spell out at least one benefit it brings for non-Meta user? I see only gains for Meta and losses for the community.
