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]
Message-ID: <ZFn74xJOtiXatfHQ@nanopsycho>
Date: Tue, 9 May 2023 09:53:07 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Paolo Abeni <pabeni@...hat.com>,
	"Kubalewski, Arkadiusz" <arkadiusz.kubalewski@...el.com>,
	Vadim Fedorenko <vadim.fedorenko@...ux.dev>,
	Vadim Fedorenko <vadfed@...a.com>,
	Jonathan Lemon <jonathan.lemon@...il.com>, poros <poros@...hat.com>,
	mschmidt <mschmidt@...hat.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org,
	"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
	"Olech, Milena" <milena.olech@...el.com>,
	"Michalik, Michal" <michal.michalik@...el.com>
Subject: Re: [PATCH RFC v6 2/6] dpll: Add DPLL framework base functions

Mon, May 08, 2023 at 09:42:50PM CEST, kuba@...nel.org wrote:
>On Mon, 8 May 2023 14:17:30 +0200 Jiri Pirko wrote:
>> >> Hmm, that would kind of embed the pin type into attr which feels wrong.  
>
>An attribute which changes meaning based on a value of another attribute
>feels even more wrong.

It wouldn't change meaning, it would be still "a label". Either on a
back of a PCI card or internal pin in a board scheme. Still the same
meaning (for mux type for example).



>
>> >Looking at the above from a different angle, the
>> >DPLL_A_PIN_FRONT_PANEL_LABEL attribute will be available only for
>> >DPLL_PIN_TYPE_EXT type pins, which looks legit to me - possibly
>> >renaming DPLL_A_PIN_FRONT_PANEL_LABEL as DPLL_A_PIN_EXT_LABEL.  
>
>Yup. Even renaming EXT to something that's less.. relative :(

Suggestion?


>
>> Well sure, in case there is no "label" attr for the rest of the types.
>> Which I believe it is, for the ice implementation in this patchset.
>> Otherwise, there is no way to distinguish between the pins.
>> To have multiple attrs for label for multiple pin types does not make
>> any sense to me, that was my point.
>
>Come on, am I really this bad at explaining this?

Or perhaps I'm just slow.


>
>If we make a generic "label" attribute driver authors will pack
>everything they want to expose to the user into it, and then some.

What's difference in generic label string attr and type specific label
string attr. What is stopping driver developers to pack crap in either
of these 2. Perhaps I'm missing something. Could you draw examples?


>
>So we need attributes which will feel *obviously* *wrong* to abuse.

Sure, I get what you say and agree. I'm just trying to find out the
actual attributes :)

Powered by blists - more mailing lists