Hm, it'll be another ABI break too. That's a bit unfortunate; I'd like to avoid a second round of compatibility ABI for older versions of head. Maybe we should just make that change now (without adding ipv6 support to dumpon/netdump, just adding union types to the ABI interface)?

It'd require minor fiddling in NETDUMPGCONF_FREEBSD12, but otherwise should be straightforward, I think.

(I don't see any good named union type for in_addr+in6_addr — outside of ofed's cma_ip_addr — but it's a widely used construct in the tree — nfs, tcp_lro, tcp_fastopen, ip_fw, pf, if_llatbl all seem to have some kind of definition.) There's in_dependaddr but I'm not sure in_addr_4in6 is the most appropriate spelling of in_addr given the way we would use it. I'm leaning towards defining a new type.

We don't provide compatibility guarantees in head, so we can just break the interface. (Hence "before 13.0.")

I think we can (ab)use struct sockaddr?

Sure, but I'm only adding "12" abi compatibility for slightly older head, not because I actually care about running 12 world (dumpon in particular) on a 13 kernel. The idea is to make the transition less painful for head consumers / crashboxes that regularly up/downgrade kernels, so the single step seems better to me.

Sockaddr isn't big enough and/or doesn't represent the right thing. It's the same size as in6_addr but doesn't logically represent an in6_addr. sockaddr_storage is closer, but huge overkill. sockaddr_in / sockaddr_in6 have a lot of redundant stuff we don't care about for this use, I think. I'll put something together.

Nothing wrong with sockaddr_storage, really. Mostly it just makes the interface more general in a way that isn't helpful (requires more boilerplate to check for EINVAL input). We can use it instead, if you would prefer.

Yeah. And whatever ambiguity surrounds other fields that matter for sockets but not hosts, eg flowid, port, etc.

Also that sockaddr_storage is an array type rather than a union and all real access requires ugly casting; and we don't save anything in header includes because we need net/if.h which means we pull in the in/in6 addr types already.

I've rototilled sockaddr_storage into just dumpon alone (to give it a shot) and it is really really ugly. And there would be a large number of additional churn involving sockaddr_in casts in netdump_client.c to finish the job. I don't think sockaddr_storage is a suitable type for this use case (and it's only used with BSD sockets for legacy API reasons).

So I don't plan to continue converting to sockaddr_storage — I'll just leave it with the address union instead.