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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 24 Aug 2022 17:31:46 +0000
From:   "Keller, Jacob E" <jacob.e.keller@...el.com>
To:     Jiri Pirko <jiri@...nulli.us>, Jakub Kicinski <kuba@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "idosch@...dia.com" <idosch@...dia.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "edumazet@...gle.com" <edumazet@...gle.com>,
        "saeedm@...dia.com" <saeedm@...dia.com>,
        "vikas.gupta@...adcom.com" <vikas.gupta@...adcom.com>,
        "gospo@...adcom.com" <gospo@...adcom.com>
Subject: RE: [patch net-next v2 4/4] net: devlink: expose the info about
 version representing a component



> -----Original Message-----
> From: Jiri Pirko <jiri@...nulli.us>
> Sent: Wednesday, August 24, 2022 1:50 AM
> To: Jakub Kicinski <kuba@...nel.org>
> Cc: netdev@...r.kernel.org; davem@...emloft.net; idosch@...dia.com;
> pabeni@...hat.com; edumazet@...gle.com; saeedm@...dia.com; Keller, Jacob
> E <jacob.e.keller@...el.com>; vikas.gupta@...adcom.com;
> gospo@...adcom.com
> Subject: Re: [patch net-next v2 4/4] net: devlink: expose the info about version
> representing a component
> 
> Tue, Aug 23, 2022 at 09:31:21PM CEST, kuba@...nel.org wrote:
> >On Tue, 23 Aug 2022 08:36:01 +0200 Jiri Pirko wrote:
> >> Tue, Aug 23, 2022 at 05:01:16AM CEST, kuba@...nel.org wrote:
> >> >I don't think we should add API without a clear use, let's drop this
> >> >as well.
> >>
> >> What do you mean? This just simply lists components that are possible to
> >> use with devlink dev flash. What is not clear? I don't follow.
> >
> >Dumping random internal bits of the kernel is not how we create uAPIs.
> >
> >Again, what is the scenario in which user space needs to know
> >the flashable component today ?
> 
> 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.

Thanks,
Jake

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ