Date: Sun, 28 Dec 2008 16:13:47 +0100 From: Tijl Coosemans <tijl@ulyssis.org> To: "Qing Li" <qingli@speakeasy.net> Cc: 'Qing Li' <qingli@freebsd.org>, freebsd-net@freebsd.org, Gerald Pfeifer <gerald@pfeifer.com>, freebsd-current@freebsd.org Subject: Re: HEADSUP: arp-v2 has been committed Message-ID: <200812281613.49404.tijl@ulyssis.org> In-Reply-To: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be> References: <20081227202117.F3B14341A3@cavin02.kulnet.kuleuven.ac.be>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 27 December 2008 21:21:25 Qing Li wrote:
> Right now I am also a bit leaning towards reintroducing
> the RTF_LLINFO flag bit. This is mainly due to the recent
> discovery of the "route" command issued with the
> "-iface/-interface" option, which conflicts with the
> way how "arp" and "ndp" is handled in the kernel.
>
> I renamed this flag bit to RTF_LLDATA because only the
> "arp" and "ndp" commands need it.
I wouldn't rename it. That breaks old code just the same.
>> I didn't want to speak up because I'm no authority in this
>> area and in the end I'm OK with any outcome, but personnaly I
>> find special-casing {NET_RT_FLAGS,0} to retrieve the L2
>> entries a bit odd.
>
> As I've indicated previously, a few ports already have the
> #ifdef RTF_LLINFO block around the sysctl() setup code.
> Perhaps it's because these ports (such as Wine) run on OS
> that does not support RTF_LLINFO (e.g. Linux?) ?
That's odd, because a quick google shows that for instance NetBSD,
OpenBSD, DragonFly and Mac OS X all define this flag.
Linux is completely different. It doens't use sysctl(3). You have to
read /proc/net/arp and /proc/net/route.
>> Surely, letting {NET_RT_FLAGS,RTF_LLINFO}
>> return L2 entries is exactly the same to implement, is far
>> more descriptive, is fully backwards compatible and
>> compatible with other sysctl operating systems like the other
>> BSDs and Mac OS X, which helps portability.
>
> I believe all of the affected ports have been updated to
> include the conditional blocks around RTF_LLINFO. So
> there is still a level of compatibility, right ?
Yes, and I'm OK with this. It's just that this makes FreeBSD 8
a special case.
>> AFAIK, the other use of RTF_LLINFO was to filter out L2
>> entries from the entire L2+L3 routing table to obtain just
>> the L3 entries. Because the L2 and L3 table have been
>> separated this filtering isn't needed anymore, but what harm
>> would it do to reintroduce RTF_LLINFO? The filtering code
>> would become a useless no-op, but you'd stay fully
>> compatible, again both backwards and with other operating systems.
>>
>> I just think that removing RTF_LLINFO was a bit too
>> aggressive an optimisation with little advantage and too many
>> disadvantages and I'd like to see it return.
>
> I believe examining the impacts of RTF_LLINFO on the ports
> was a good exercise even if we have to rejuvenate it.
>
> I hope we could reach a consensus soon now that we have more
> input from the ports developers.
>
> Please provide your input ...
If it's easy to reintroduce it and become backwards compatible I
would do it. Like Julian said, you can give it the value 0. It
would be nice if the kernel tested for the old value as well,
perhaps behind an #ifdef COMPAT_FREEBSD*. That way when people
upgrade to FreeBSD 8 all their ports compiled under FreeBSD 7
keep working.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200812281613.49404.tijl>