Am 29.10.25 um 20:57 schrieb Xin Long:

On Wed, Oct 29, 2025 at 12:22 PM Stefan Metzmacher [off-list ref] wrote:

quoted

Hi Xin,

quoted

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 <redacted>
Signed-off-by: Xin Long <lucien.xin@gmail.com>

...

quoted

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

metze