On Wed, Aug 24, 2022 at 06:46:13PM +0000, Keller, Jacob E wrote: > > > > -----Original Message----- > > From: Jakub Kicinski > > Sent: Wednesday, August 24, 2022 11:12 AM > > To: Keller, Jacob E > > Cc: Jiri Pirko ; netdev@vger.kernel.org; davem@davemloft.net; > > idosch@nvidia.com; pabeni@redhat.com; edumazet@google.com; > > saeedm@nvidia.com; vikas.gupta@broadcom.com; gospo@broadcom.com > > Subject: Re: [patch net-next v2 4/4] net: devlink: expose the info about version > > representing a component > > > > On Wed, 24 Aug 2022 17:31:46 +0000 Keller, Jacob E wrote: > > > > Well, I thought it would be polite to let the user know what component > > > > he can pass to the kernel. Now, it is try-fail/success game. But if you > > > > think it is okay to let the user in the doubts, no problem. I will drop > > > > the patch. > > > > > > I would prefer exposing this as well since it lets the user know which names are > > valid for flashing. > > > > > > I do have some patches for ice to support individual component update as well > > I can post soon. > > > > Gentlemen, I had multiple false starts myself adding information > > to device info, flashing and health reporters. Adding APIs which > > will actually be _useful_ in production is not trivial. I have > > the advantage of being able to talk to Meta's production team first > > so none of my patches made it to the list. > > > > To be clear I'm not saying (nor believe) that Meta's needs or processes > > are in any way "the right way to go" or otherwise should dictate > > the APIs. It's just an example I have direct access to. > > > > I don't think I'm out of line asking you for a clear use case. > > Just knowing something is flashable is not sufficient information, > > the user needs to know what the component actually describes and > > what binary to use to update it. > > > > At least for ice, the same binary would be used for individual component update. the PLDM firmware binary header describes where each component is within it, and is decoded by lib/pldmfw, we just need to translate the PLDM header codes to the userspace names. > > The old tools which Intel supports do have support for such an individual component update, but the demand wasn't very high, so I never got around to posting the patches to support this. There are some corner cases where it might be helpful to flash (or reflash) a single component, but it seems somewhat less useful for most end-users and mostly would be useful for internal engineering and debugging. > > Users would still need to know what each component is, and there isn't much the kernel API itself can do here. We do document a short description, but that is going to be limited in usefulness since it likely depends on a lot of related knowledge. > I agree with this. Individual component updates are most useful in a dev/debug environment rather than in production. I'm not sure there is value in exporting this all the way out to kernel APIs.