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

On Tue, 28 Jul 2026 21:57:21 -0400 Chuck Lever wrote:
> > To me this is an ugly one-off workaround that doesn't fit into=20
> > the proto_ops (only TLS will use it). And you seem to net out
> > to the same LOC on SUNRPC side with and without this? =20
>=20
> It=E2=80=99s not about LOC. It=E2=80=99s about not cluttering the normal =
I/O
> path with a lot of exception processing to handle TLS Alert
> records. The CMSG API is very difficult to use and leaks the
> alert messages into I/O buffers (which for in-kernel consumers
> are page cache pages). It=E2=80=99s piss-poor API design.

I'm not arguing that it's amazing. Doesn't mean we will YOLO
a special proto callback for every protocol stacking :/

> > There needs to be a very strong reason for us to add APIs for
> > in kernel consumers. =20
>=20
> This is not a helpful position. Your objection is the same
> every time, treating the in-kernel users as second-class
> citizens.

No, it's not a second class citizen. But kernel consumers have a
tendency to break all abstractions and insert hacks all over the place
just because they are not forced to go via uAPI boundary which forces
people to think about the API design.

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.

> You haven=E2=80=99t provided a single alternative to address
> our concerns, and you have not explained why an additional API
> is a problem.
>=20
> Please put down your hostility and elaborate. You seem to be
> the only one who has a problem with any of this.

True. We should remove maintainers and just commit obvious LLM slop.