On Mon, Jan 26, 2009 at 04:42:55PM -0500, der Mouse wrote: > >> How much of a pain would it be to grow [if_flags]? struct ifnet is > >> prepared for it; if_flags is 32-bit-aligned and the next field after > >> it is a pad field. > > As long as you add a second field, it should not be a problem. If > > you want to make if_flags itself 32bit, you have to deal with > > endianess, don't you? > > I can't see why; if_flags doesn't appear anywhere where endianness is > relevant as far as I know (no wire protocols, for example). I didn't > have any endianness issues when just growing the field on 1.4T, and I > use hardware of each endianness regularly. And if endianness mattered, > wouldn't we have such issues today with the existing field, since it's > already more than one byte? I'd say it matters for binary compatibility. However it's not that important for ifnet anyway. Exposing the new flags to userland will be a different issue though, given the way ifreq works. -- Quentin Garnier - cube%cubidou.net@localhost - cube%NetBSD.org@localhost "See the look on my face from staying too long in one place [...] every time the morning breaks I know I'm closer to falling" KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
Attachment:
pgp2atQ5M9KTc.pgp
Description: PGP signature