[randomizedcoder]

Linux 7.1 changed two APIs that Homa uses, so main doesn't build on 7.1, 7.2 or 7.3:

• proto.recvmsg lost addr_len (8341c989ac77). This adds homa_recvmsg_proto, a small adapter that does what sock_common_recvmsg used to: it starts addr_len at 0, calls homa_recvmsg, and sets msg->msg_namelen on success. homa_recvmsg and its unit tests are unchanged.
• net_hotdata.rps_sock_flow_table became an rps_tag_ptr (dd378109d20f). homa_set_softirq_cpu now uses rps_tag_to_table/rps_tag_to_mask on 7.1+, mirroring the kernel's rps_record_sock_flow.

Builds against 6.12, 6.19.9, 7.0.14, 7.1.13, 7.2.12, 7.3-rc7 and 7.3, and the unit tests pass. Also loaded in a 7.3.0 VM, where loopback request/response RPCs (100 B to 1 MB) complete through the new recvmsg path and dmesg stays clean.

No test: compile-time only, and the unit harness builds against the 6.17.8/7.0.14 objects, where the new code isn't compiled.

Not covered here: 6.18 stable backported the recvmsg change in 6.18.40 and the sockaddr_unsized bind change in 6.18.57, so current 6.18 LTS still doesn't build. That needs a separate, finer-grained gate: test/mock.c uses SOCKADDR for connect, which 6.18.57 did not convert.

🤖 Generated with Claude Code

[breakertt]

There were some discussions on this between John and Tiara just recently #110 (comment)

I agree, and I also think we should move support from a random kernel version number (i.e. 6.17.8) to the latest LTS version, if we mainly maintain support for one kernel version.

I am trying to introduce some basic CI (#119) so we can quickly know when it doesn’t build.

But it still depends on John, as he is mainly working on this repo and his convenience matters most IMO.

[randomizedcoder]

Thanks for the quick reply! I've got a flake.nix and modular nix that does a lot of static analysis, fuzzing, and will test against a wide range of kernels. This is easy to hook up with CI.

[breakertt]

Unfortunately I am not a big fan of Nix, but I am also not anti-Nix. Overall I feel we should be able to have those abilities without Nix, for less maintenance burden. Do you think that if we use Nix for CI, the CI will still be easy to understand for non-NixOS users? If so, I am actually open to that.

[breakertt]

Unfortunately I am not a big fan Nix, but I am also anti Nix. Just overall I feel we should able to have those abilities without Nix for less maintaince burden? Do you think if we use Nix for CI - the CI will easier to understand for non NixOS user? If so I am actually open to that.

Sorry I mean I am not anti-NixOS, it was a typo 🫣