Re: [RFC PATCH net-next v2 6/6] devlink: add overwrite mode to flash update

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

On 7/21/2020 10:04 AM, Jakub Kicinski wrote:
> On Tue, 21 Jul 2020 15:53:56 +0200 Jiri Pirko wrote:
>> Mon, Jul 20, 2020 at 05:51:59PM CEST, kubakici@wp.pl wrote:
>>> On Mon, 20 Jul 2020 12:09:53 +0200 Jiri Pirko wrote:  
>>>> This looks odd. You have a single image yet you somehow divide it
>>>> into "program" and "config" areas. We already have infra in place to
>>>> take care of this. See DEVLINK_ATTR_FLASH_UPDATE_COMPONENT.
>>>> You should have 2 components:
>>>> 1) "program"
>>>> 2) "config"
>>>>
>>>> Then it is up to the user what he decides to flash.  
>>>
>>> 99.9% of the time users want to flash "all". To achieve "don't flash
>>> config" with current infra users would have to flash each component   
>>
>> Well you can have multiple component what would overlap:
>> 1) "program" + "config" (default)
>> 2) "program"
>> 3) "config"
> 
> Say I have FW component and UNDI driver. Now I'll have 4 components?
> fw.prog, fw.config, undi.prog etc? Are those extra ones visible or just
> "implied"? If they are visible what version does the config have?
> 
> Also (3) - flashing config from one firmware version and program from
> another - makes a very limited amount of sense to me.
> 

Right, this is actually one of the potential problems I've been told
about: if the config doesn't match the firmware it's supposed to work,
but the "overwrite config" option is partially there to help have a way
out in case the config and firmware aren't in sync and something goes wrong.

>>> one by one and then omit the one(s) which is config (guessing which 
>>> one that is based on the name).
>>>
>>> Wouldn't this be quite inconvenient?  
>>
>> I see it as an extra knob that is actually somehow provides degradation
>> of components.
> 
> Hm. We have the exact opposite view on the matter. To me components
> currently correspond to separate fw/hw entities, that's a very clear
> meaning. PHY firmware, management FW, UNDI. Now we would add a
> completely orthogonal meaning to the same API. 
> 
> Why?
> 
> In the name of "field reuse"?
> 

Right. I understand that other hardware works differently and has all
config separated to separate distinct components, but I think it would
be needlessly confusing to have separate component names. Plus, as I
said in another thread: I can't really separate the two components when
I update. I have to send the combined block to firmware with the flag
indicating how it should do preservation/merging. So I can't really do
"just settings" anyways, meaning that it really would be two components
which overlap. Plus, I wouldn't really have a separate "info" display.

Ultimately it ends up feeling like a significant hack of the component
name if I go that route.