Re: [PATCH RFC v1] rds: Expose feature parameters via sysfs and ELF note

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Jun 10, 2025 at 10:30:27PM +0200, Andrew Lunn wrote:
> > +What:		/sys/module/rds/parameters/rds_ioctl_set_tos
> > +Date:		Jun 2025
> > +Contact:	rds-devel@oss.oracle.com
> > +Description:
> > +		The RDS driver supports the mechanism to set on a socket
> > +		the Quality of Service.
> > +
> > +		The returned value is the socket ioctl number and this is read-only.
> 
> From this, can i imply that the IOCTL number has changed sometime in
> the past? That would be an ABI break, which is not good.

Not that I am aware of. But this is more of putting all of the different
exposed ABIs that exist in the driver instead of listing specific ones.

> 
> More likely, none of the IOCTL numbers have changed. All you need to
> know is if the file exists or not. So i would makes the files the same

Right..
> as /dev/null.

Not sure I follow. Make them the same a /dev/null? Meaning link them to
/dev/null when the module is loaded?
> 
> Also, these are not actually parameters to the module, so putting them
> in parameters seems confusing at best.

Right, that is the one part I was not sure about - another approach was
to create a new sysfs tree. But it would be more code as we have to
register all of that during initialization, while the module_param does it
very nicely.

> 
> I doubt this is the first time this problem has been addressed in the
> kernel. Maybe look at:
> 
> $ find /sys -name "*features*"
> /sys/kernel/security/apparmor/features
> /sys/kernel/cgroup/features
> 
> and see if you can copy/paste ideas/code from there. And also ask them
> if this was a good idea, or they say not don't do that, it was a bad
> idea, just call the IOCTL and test for ENOIOCTLCMD.

Good thinking - let me dig in that and also CC the authors of those to
get their feedback.

Thank you!
> 
> 	Andrew