netdev - Re: [rds-devel] [PATCH RFC v1] Feature reporting of RDS driver.

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] [day] [month] [year] [list]

Message-ID: <aFBYIdaq8NOk_v3U@slm.duckdns.org>
Date: Mon, 16 Jun 2025 07:45:05 -1000
From: Tejun Heo <tj@...nel.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Cc: allison.henderson@...cle.com, netdev@...r.kernel.org,
	linux-rdma@...r.kernel.org, rds-devel@....oracle.com, guro@...com,
	kernel-team@...com, surenb@...gle.com, peterz@...radead.org,
	hannes@...xchg.org, mkoutny@...e.com, cgroups@...r.kernel.org,
	andrew@...n.ch
Subject: Re: [rds-devel] [PATCH RFC v1] Feature reporting of RDS driver.

Hello,

On Tue, Jun 10, 2025 at 07:15:31PM -0400, Konrad Rzeszutek Wilk wrote:
...
> > That said, the sysfs approach is pretty straightforward and has worked well
> > for us. One thing which we didn't do (yet) but maybe useful is defining some
> > conventions to tell whether a given feature or option should be enabled by
> > default so that most users don't have to know which features to use and
> > follow whatever the kernel release thinks is the best default combination.
> 
> I see. With that in mind, would it have helped if each feature had its
> own sysfs file with a tri-state or such?

I don't see why that wouldn't work but maybe a bit too elaborate?

> In regards to the existing 'feature' sysfs attribute:
> 
> How were you thinking to address API/ABI semantic breakage? Say older
> versions implemented a "foobar" feature but never kernels implement a
> much better way, but with a change the semantics (say require extra parameters,
> etc).  Would you expose both of them via the 'feature' sysfs attribute: "foobar\nfoobar_v2" ?
> 
> What would be then the path for removing the old one? Would you just
> drop "foobar" and only expose "foobar_v2" ?

I don't think there's one good answer but here's one:

- Each token in the files represents an optional feature.

- A feature preceded by + is expected to be enabled (or used) by default. A
  feature preced by - is expected to be not used.

- When introducing v2, make v2 +, the old one -.

- After users are reasoanbly migrated, start generating warning on v1 usages.

- Remove v1.

Thanks.

-- 
tejun