[extrowerk]

Adds illumos (OmniOS) support: interface enumeration through getifaddrs plus
the illumos-specific ioctls.

What it does

• New src/os/illumos module, selected for target_os = "illumos".
• lifreq.rs reproduces struct lifreq and the SIOCGLIFFLAGS /
  SIOCGLIFMTU ioctl numbers, because libc does not bind them for
  illumos. The layout follows <net/if.h>: 376 bytes on LP64, with lifr_type
  at offset 36 and the union at offset 40 sized for lif_nd_req.
• A unit test asserts the struct size and both ioctl numbers, since they are
  derived from the size via _IOWR and a wrong layout silently produces
  failing ioctls.
• Interface flags and MTU are read per logical interface through those ioctls.

CI

An illumos workflow cross-builds the tests with the cross-rs image and runs them
in an OmniOS VM (adapted from the net-tools one).

Tested

OmniOS r151058, in a non-global zone, as a dependency of rayfish (through
netwatch): interface enumeration works and the daemon runs normally.
sizeof(struct lifreq) was cross-checked with a C program on the same system
(376).

Notes

• Unlike other unix targets, illumos declares ioctl(fd, request: c_int, ...),
  so request codes are plain c_int.
• Not verified: behaviour on illumos distributions other than OmniOS, and
  32-bit (ILP32) builds, where struct lifreq differs.

Related

Used by the illumos support in net-tools (netwatch), which depends on this change.
n0-computer/net-tools#255

[extrowerk]

netdev: the two earlier commits were squashed into 991bbbf, and 7e0ac13 fixes the lifreq layout (adds lifr_type, union sized for lif_nd_req, test asserts 376 bytes).

[shellrow]

Thanks for the contribution and for adding illumos support!

I’ll review the changes soon.

I noticed that the illumos cross build CI check is failing because cargo nextest archive uses --locked, but netdev intentionally doesn’t track Cargo.lock. Could you remove the --locked flag from this step?

Thanks again!

[extrowerk]

Removed --locked, thanks. Pushed in 1f9deb9

[shellrow]

I’ve reviewed the changes and found no blocking issues or regressions affecting existing platforms.
Thanks!