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

Message-ID: <aEi8k1yKBn0egAui@char.us.oracle.com>
Date: Tue, 10 Jun 2025 19:15:31 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: Tejun Heo <tj@...nel.org>
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.

On Tue, Jun 10, 2025 at 11:32:40AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Tue, Jun 10, 2025 at 04:47:23PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, Jun 10, 2025 at 12:27:24PM -0400, Konrad Rzeszutek Wilk via rds-devel wrote:
> > > Hi folks,
> > 
> > Hi cgroup folks,
> > 
> > Andrew suggested that I reach out to you all since you had implemented
> > something very similar via:
> > 
> > 3958e2d0c34e1
> > 01ee6cfb1483f
> > 
> > And I was wondering if you have have feedback on what worked for you,
> > best practices, etc.
> 
> I don't know RDS at all, so please take what I say with a big grain of salt.

It is just a driver. One talks to it via socket.. But it can do extra
things based on setsocket/getseocket and such.

> 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?

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" ?

Thank you!
> 
> Thanks.
> 
> -- 
> tejun