Date: Sat, 15 Jan 2000 12:55:15 -0500 From: David Wiggins <dwiggins@bbn.com> To: freebsd-hackers@freebsd.org Subject: propose enlarging ifnet.if_flags Message-ID: <200001151755.MAA03830@elektra.bbn.com>
next in thread | raw e-mail | index | archive | help
I would like to suggest changing struct ifnet.if_flags from a short to an int and changing ifreq.ifru_flags to match. For the project I have been working on, we've needed to define three new interface flags. All 16 current flags are allocated, so we had to add more bits. We didn't want to use IFF_LINK0-LINK2 for our flags because those are "per link layer defined" and our flags don't exactly fit that description. Briefly, one flag identifies radio interfaces, another says if the interface is capable of issuing predictions about its future state, and the third tells if the interface is connected to a pointable antenna. Some consequences of such a change: o kernel code that copies if_flags to another variable should be updated to use the new type for if_flags, though such code would probably continue to work (after recompiling) even without changing the type because the additional high bits would be dropped when copying to a short. o changing struct ifreq affects the interface to userland. Maybe this triggers some shlib-version-numbering rules? On little-endian machines, userland programs that use ifr_flags should continue to work without even recompiling since the lower two bytes of flags will land in the same place. This would break big-endian machines without recompiling. As with the kernel, userland programs that copy the flags should ideally be changed to use the new type. o userland programs that read struct ifnets from kernel memory (e.g., netstat) would also need recompiling. o divergence with [Open|Net]BSD unless they change too. I should confess here that the change I've requested is not the change we made. We were worried about possible binary compatibility problems, so we added a short "extension flags" field at the end of struct ifnet, and added a new ioctl to get the extension flags. But this is a kludge, and we'd like to be able to do away with it by enlarging the existing flags field. I see that in if.h:1.50 ifreq.ifru_flags changed from a short to an array of two shorts, with the second short being the previous flags. I think this is OK; just change it to an array of two ints. The size of struct ifreq still won't change because ifru_flags is part of a union containing a sockaddr, which is bigger than two ints. The checkin message for if.h:1.48 mentions adding fields to struct ifreq; perhaps this change could be done at this same time. Note: I just unsubscribed from the -digest form of this list and subscribed to the non-digest address, but I'm not sure the latter has gone through yet, so please cc: me on any replies. Thanks. David Wiggins To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001151755.MAA03830>