On Wed, Nov 26, 2014 at 12:50 AM, Masao Uebayashi <uebay...@gmail.com> wrote: > On Wed, Nov 26, 2014 at 12:29 AM, Ryota Ozaki <ozak...@netbsd.org> wrote: >> Yes, we can extend if_flags to int by unifying with if__pad1, and it works >> for the kernel and for old userland programs on little endian machines. >> However, it doesn't work for old userland programs on big endian machines, >> IIUC. An old userland program, say netstat, which uses kvm(3) reads >> if_flags as short. On a LE machine, netstat can see lower-half of if_flags >> (int) of a new kernel as expected. OTOH, on a BE machine, netstat sees >> upper-half of the value. > > I'd change if__pad1 to if_flags2 and define IFF2_SLOWTIMO_MPSAFE etc.
Hmm, I think it's a last resort. I don't want to do something like (ifp->if_flags & IFF_XXX) && (ifp->if_flags2 & IFF_XXX2) if possible. I'm thinking more to avoid the separation. > >>>> I don't understand how kvm(3) works though, if we don't change existing >>>> members of struct ifnet, can old netstat(1) run on a new kernel that >>>> adds a value hidden in _KERNEL to struct ifnet? >>> >>> I think adding a new member at the tail doesn't change member offsets, >>> so netstat(1) *should* keep working. >>> >>> But for future, netstat(3) should use kvm(3), so that it keeps working >>> even after struct ifnet changes. >> >> Hmm, I fail to understand what you mean. netstat should use kvm? or >> shouldn't use? > > Sorry, I meant s/kvm(3)/sysctl(3)/... Got it. And no objection. Thanks, ozaki-r