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

[Chuck Lever]

On Wed, Jul 29, 2026, at 8:23 AM, Sabrina Dubroca wrote:
> 2026-07-28, 22:51:30 -0400, Chuck Lever wrote:
>> On Tue, Jul 28, 2026, at 10:30 PM, Jakub Kicinski wrote:

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