Re: [PATCH v2] rds: Expose feature parameters via sysfs

[Andrew Lunn <andrew@lunn.ch>]

> I could not for the life of me get the kernel to compile without
> CONFIG_SYSFS, but here is the patch with the modifications you
> enumerated:

Please take a read of:

https://docs.kernel.org/process/submitting-patches.html

and

https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html

You need a new thread for every version of the patch. You should also
put the tree into the Subject: line, etc.

> diff --git a/Documentation/ABI/stable/sysfs-driver-rds b/Documentation/ABI/stable/sysfs-driver-rds

I could be bike shedding too much, but RDS is not a driver. It is a
socket protocol, which you can layer on top of a few different
transport protocols. So i don't think it should have -driver- in the
filename.

> new file mode 100644
> index 000000000000..d0b4fe0d3ce4
> --- /dev/null
> +++ b/Documentation/ABI/stable/sysfs-driver-rds
> @@ -0,0 +1,10 @@
> +What:          /sys/kernel/rds/features
> +Date:          June 2025
> +KernelVersion: 6.17
> +Contact:       rds-devel@oss.oracle.com 
> +Description:   This file will contain the features that correspond
> +               to the include/uapi/linux/rds.h in a string format.
> +
> +	       The intent is for applications compiled against rds.h
> +	       to be able to query and find out what features the
> +	       driver supports.

Is that enough Documentation for somebody to make use of this file
without having to do a deep dive into the kernel sources? If i need to
do a deep dive, i might just as well handle the EOPNOTSUPP return
values.

> +static ssize_t features_show(struct kobject *kobj, struct kobj_attribute *attr,
> +			     char *buf)
> +{
> +	return snprintf(buf, PAGE_SIZE, "get_tos\n"
> +			"set_tos\n"
> +			"socket_cancel_sent_to\n"
> +			"socket_get_mr\n"
> +			"socket_free_mr\n"
> +			"socket_recverr\n"
> +			"socket_cong_monitor\n"
> +			"socket_get_mr_for_dest\n"
> +			"socket_so_transport\n"
> +			"socket_so_rxpath_latency\n");

This is ABI. User space is going to start parsing this. Maybe we
should add both here, and in the documentation, something like:

  New lines will be added at random places within the file as new
  features are added.

This makes it clear that any code which tests line 4 for
"socket_free_mr" could break in the future. The whole file needs to be
searched for a feature.

	Andrew