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

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

On Wed, Nov 26, 2014 at 12:50 AM, Masao Uebayashi <uebayasi%gmail.com@localhost> wrote:
> On Wed, Nov 26, 2014 at 12:29 AM, Ryota Ozaki <ozaki-r%netbsd.org@localhost> 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