RE: HEADSUP: arp-v2 has been committed


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


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 ?


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

-- Qing












_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • RE: HEADSUP: arp-v2 has been committed
    ... Right now I am also a bit leaning towards reintroducing ... I renamed this flag bit to RTF_LLDATA because only the ... Perhaps it's because these ports run on OS ... there is still a level of compatibility, ...
    (freebsd-net)
  • Re: HEADSUP: arp-v2 has been committed
    ... I renamed this flag bit to RTF_LLDATA because only the ... Perhaps it's because these ports run on OS ... there is still a level of compatibility, ... It's just that this makes FreeBSD 8 ...
    (freebsd-net)
  • Re: HEADSUP: arp-v2 has been committed
    ... I renamed this flag bit to RTF_LLDATA because only the ... Perhaps it's because these ports run on OS ... there is still a level of compatibility, ... It's just that this makes FreeBSD 8 ...
    (freebsd-current)
  • Re: some issues with /usr/sbin/service
    ... I have a number of ports installed ... daemons but I don't want the daemon but some other functionality. ... Should I really have to go through and explicitly set the xxx_enable flags ... If the requirement is that all installed rc.d scripts have a xxx_enable flag ...
    (freebsd-stable)
  • Re: Portupgrading - portauditing
    ... > installed (window injection vulnerability). ... Even the portupgrade -f flag won't work and simply building ... > the port manually is also disabled for flagged ports. ... building ports despite vulnerabilities: ...
    (freebsd-questions)