> The reason to introduce the LIF ones was that struct ifreq couldn't hold
> a sockaddr_in6.
Ah, I never knew that -- though it does seem obvious in retrospect :-)
But I'm still not sure I understand the need for such a disruptive change
-- it seems like we could've:
1. Changed the old `ifreq' to be `oifreq'.
2. Introduced a new `ifreq' with a sockaddr_storage member.
3. Changed `SIOCGIFCONF' to use a new ioctl number and new `ifreq'.
4. Renamed the old ioctl number (which would continue to use
`oifreq') to be `OSIOCGIFCONF'.
5. Supported both SIOCGIFCONF and OSIOCGIFCONF in the kernel.
Wouldn't this have preserved both source and binary compatibility?
> Other vendors might have introduced a struct ifreq6, but having a common
> "large" ifreq instead of a separate "IPv4" and "IPv6" one seemed like
> the better approach.
Google returns no interesting hits for 'ifreq6'. It looks like BSD just
increased ths size of the existing ifreq structure -- but that many
applications use getifaddrs() and ifaddrlist() so they were insulated from
the change. Of course, we don't (publically) have those on Solaris.
In any case, this seems like a portability headache.
--
meem
_______________________________________________
networking-discuss mailing list
[email protected]
