Re: struct ifnet and ifaddr handling [was: Re: Making global variables of if.c MPSAFE]

[Ryota Ozaki <ozaki-r%netbsd.org@localhost>]

On Tue, Nov 25, 2014 at 10:02 PM, Masao Uebayashi <uebayasi%gmail.com@localhost> wrote:
> On Tue, Nov 25, 2014 at 7:18 PM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> wrote:
>> Hmm, if_flags.
>>
>> http://mail-index.netbsd.org/tech-net/2009/01/27/msg000985.html
>>
>> Do we have to care about kvm(3) users (i.e., netstat) as well as
>> the callout_t issue?
>
> For new flags, you can reuse if__pad1.

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 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?

  ozaki-r