Re: [PATCH net-next v2 2/6] net: Introduce read_sock_rectype proto_ops for control record delivery

On Wed, Jul 29, 2026, at 8:23 AM, Sabrina Dubroca wrote:

2026-07-28, 22:51:30 -0400, Chuck Lever wrote:

quoted

On Tue, Jul 28, 2026, at 10:30 PM, Jakub Kicinski wrote:

quoted

quoted

You just need to try a little harder to produce a better solution.
Rework or augment existing callbacks to let your achieve the behavior
you want.

My original approach was to add a new read_sock variant because I
suspected you wouldn’t want read_sock itself to grow another argument.

Given that there's only 2 existing consumers of read_sock (strp and
nvme, and I'm not sure why strp/sockmap use it at all) [1], and 3
arguments to read_sock, adding an argument would be ok IMO. The
implementation (tls_sw_read_sock/tls_sw_read_sock_rectype) ends up
being a small wrapper around a function that does the actual work with
a NULL check, might as well propagate that to the callers.

For me the problem is more that this new argument is very specific to
TLS, and dropping something TLS-specific in a generic API (struct
proto_ops) is quite ugly. If we want to make this generic, we're back
to cmsg (or something cmsg-like).

Fair enough.


-- 
Chuck Lever