Re: [PATCH net-next v4 02/15] net: build socket infrastructure for QUIC protocol

On Thu, Oct 30, 2025 at 7:29 AM Stefan Metzmacher <[email protected]> wrote:
>
> Am 29.10.25 um 20:57 schrieb Xin Long:
> > On Wed, Oct 29, 2025 at 12:22 PM Stefan Metzmacher <[email protected]> wrote:
> >>
> >> Hi Xin,
> >>
> >>> This patch lays the groundwork for QUIC socket support in the kernel.
> >>> It defines the core structures and protocol hooks needed to create
> >>> QUIC sockets, without implementing any protocol behavior at this stage.
> >>>
> >>> Basic integration is included to allow building the module via
> >>> CONFIG_IP_QUIC=m.
> >>>
> >>> This provides the scaffolding necessary for adding actual QUIC socket
> >>> behavior in follow-up patches.
> >>>
> >>> Signed-off-by: Pengtao He <[email protected]>
> >>> Signed-off-by: Xin Long <[email protected]>
> >>
> >> ...
> >>
> >>> +module_init(quic_init);
> >>> +module_exit(quic_exit);
> >>> +
> >>> +MODULE_ALIAS("net-pf-" __stringify(PF_INET) "-proto-261");
> >>> +MODULE_ALIAS("net-pf-" __stringify(PF_INET6) "-proto-261");
> >>
> >> Shouldn't this use MODULE_ALIAS_NET_PF_PROTO(PF_INET, IPPROTO_QUIC)
> >> instead?
> >>
> > Hi, Stefan,
> >
> > If we switch to using MODULE_ALIAS_NET_PF_PROTO(), we still need to
> > keep using the numeric value 261:
> >
> >    MODULE_ALIAS_NET_PF_PROTO(PF_INET, 261);
> >    MODULE_ALIAS_NET_PF_PROTO(PF_INET6, 261);
> >
> > IPPROTO_QUIC is defined as an enum, not a macro. Since
> > MODULE_ALIAS_NET_PF_PROTO() relies on __stringify(proto), it can’t
> > stringify enum values correctly, and it would generate:
> >
> >    alias:          net-pf-10-proto-IPPROTO_QUIC
> >    alias:          net-pf-2-proto-IPPROTO_QUIC
>
> Yes, now I remember...
>
> Maybe we can use something like this:
>
> -  IPPROTO_QUIC = 261,          /* A UDP-Based Multiplexed and Secure Transport */
> +#define __IPPROTO_QUIC 261     /* A UDP-Based Multiplexed and Secure Transport */
> +  IPPROTO_QUIC = __IPPROTO_QUIC,
>
> and then
>
> MODULE_ALIAS_NET_PF_PROTO(PF_INET, __IPPROTO_QUIC)
>
> In order to make things clearer.
>
> What do you think?
>
That might be a good idea to make things clearer later on.

But for now, I’d prefer not to add something special just for QUIC in
include/uapi/linux/in.h.  We can revisit it later together with SCTP,
L2TP, and SMC to keep things consistent.

Thanks.