netdev - Re: [RFC PATCH v3 net-next] Documentation: devlink: Add devlink-sd

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: <Zc8XjcRLOH3TXHED@nanopsycho>
Date: Fri, 16 Feb 2024 09:06:37 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
Cc: William Tu <witu@...dia.com>, Jacob Keller <jacob.e.keller@...el.com>,
	bodong@...dia.com, jiri@...dia.com, netdev@...r.kernel.org,
	saeedm@...dia.com,
	"aleksander.lobakin@...el.com" <aleksander.lobakin@...el.com>
Subject: Re: [RFC PATCH v3 net-next] Documentation: devlink: Add devlink-sd

Fri, Feb 16, 2024 at 02:58:36AM CET, kuba@...nel.org wrote:
>On Thu, 15 Feb 2024 14:19:40 +0100 Jiri Pirko wrote:
>> >Maybe the first thing to iron out is the life cycle. Right now we
>> >throw all configuration requests at the driver which ends really badly
>> >for those of us who deal with heterogeneous environments. Applications
>> >which try to do advanced stuff like pinning and XDP break because of
>> >all the behavior differences between drivers. So I don't think we
>> >should expose configuration of unstable objects (those which user
>> >doesn't create explicitly - queues, irqs, page pools etc) to the driver.
>> >The driver should get or read the config from the core when the object
>> >is created.  
>> 
>> I see. But again, for global objects, I understand. But this is
>> device-specific object and configuration. How do you tie it up together?
>
>We disagree how things should be modeled, sort of in principle.
>I think it dates all the way back to your work on altnames.
>We had the same conversation on DPLL :(
>
>I prefer to give objects unique IDs and a bunch of optional identifying
>attributes, rather than trying to build some well organized hierarchy.
>The hierarchy often becomes an unnecessary constraint.

Sure, no problem on having floating objects with ids and attributes.
But in case they relate to HW configuration, you need to somehow glue
them to a device eventually. This is what I'm missing how you envision
it. The lifetime of object and glue/unglue operations.