netdev - Re: [PATCH net-next 00/11] mlxsw: extend line card model by devices and info

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 30 May 2022 12:54:08 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Jiri Pirko <jiri@...nulli.us>
Cc:     Ido Schimmel <idosch@...sch.org>, Ido Schimmel <idosch@...dia.com>,
        netdev@...r.kernel.org, davem@...emloft.net, pabeni@...hat.com,
        jiri@...dia.com, petrm@...dia.com, dsahern@...il.com,
        andrew@...n.ch, mlxsw@...dia.com
Subject: Re: [PATCH net-next 00/11] mlxsw: extend line card model by devices
 and info

On Sun, 29 May 2022 11:23:01 +0200 Jiri Pirko wrote:
> >Let's step back and look from the automation perspective again.
> >Assuming we don't want to hardcode matching "lc$i" there how can 
> >a generic FW update service scan the dev info and decide on what
> >dev flash command to fire off?  
> 
> Hardcode matching lc$i? I don't follow. It is a part of the
> version/component name.
> So if devlink dev info outputs:
> lc2.fw 19.2010.1310
> then you use for devlink dev flash:
> devlink dev flash pci/0000:01:00.0 component lc2.fw file mellanox/fw-AGB-rel-19_2010_1312-022-EVB.mfa2
> Same name, same string.
> 
> What am I missing?

Nevermind, I think we can iterate over all the groupings.
Since I hope you agreed that component has an established
meaning can we use group instead?

> >> Also, to avoid free-form, I can imagine to have per-linecard info_get() op
> >> which would be called for each line card from devlink_nl_info_fill() and
> >> prefix the "lcX" automatically without driver being involved.
> >> 
> >> Sounds good?  
> >
> >Hm. That's moving the matryoshka-ing of the objects from the uAPI level
> >to the internals. 
> >
> >If we don't do the string prefix but instead pass the subobject info to
> >the user space as an attribute per version we can at least avoid
> >per-subobject commands (DEVLINK_CMD_LINECARD_INFO_GET). Much closer to
> >how health reporters are implemented than how params are done, so I
> >think it is a good direction.  
> 
> Sorry, I'm a bit lost. Could you please provide some example about how
> you envision it? For me it is a guessing game :/
> My guess is you would like to add to the version nest where
> DEVLINK_ATTR_INFO_VERSION_NAME resides for example
> DEVLINK_ATTR_LINECARD_INDEX?
> 
> Correct?

Yup.