additional ifreq accessors?

[Brooks Davis]

In r331797 I added a public accessor for the ifru_data member of
struct ifreq (using a union to access the right version of the struct
depending on the caller's ABI and creating a pointer from the 32-bit
version's integer representation).  I've also recently exposed versions
for ifru_buffer.  All non-pointer members are currently accessed by
treating the structure as a struct ifreq (even it's a struct ifreq32.)
This works because the structure layout doesn't differ for other members
and I believe it is safe even in the present of aggressive LTO because
the actual type of the object in userspace can never be observed by the
compiler.

In CheriBSD, our initial port used 256-bit (wide and aligned)
pointers.  This caused padding to be inserted between ifr_name and
ifr_ifru making the aliasing approach not work.  As such I switched all
access to ifr_ifru members to use accessors.  We have decided that
256-bit is not viable for commercial deployment (duh) and are slowly
removing 256-bit specific things from our tree.

The full set of accessors can be seen at (just pretend the __capability
qualifiers aren't there): 

https://github.com/CTSRD-CHERI/cheribsd/blob/602d2c547b1cf917998833003ada80b564861153/sys/net/if_var.h#L828-L849

My question for the lists is: should we adopt the
more-technically-correct accessors in FreeBSD or stick with
slightly-cheaper and more conventional aliasing approach[0]?  If the
former, I'll prepare a diff, if the latter I'll reduce my diffs locally.

-- Brooks

[0] To ensure use of the accessors in the kernel we don't define the
macros used to make ifr_ifru pseudo-transparent when _KERNEL is defined.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20200407/8a5a4af7/attachment.sig>