On Sat, 17 Nov 2007, Bruce M Simpson wrote:

> I take more time out of the weekend to shout about legacy kludge...
> We can put a nice big comment in that says "this is an old crusty hack, it
> is NOT SUPPORTED for new code", but it's better not to have kludges there in
> the first place.
> We can bring it back in the 7-current train to keep folk happy for now,
> sure, but I strongly suggest we get rid of it in future, otherwise, we risk
> not taking the step of progress -- EBIKESHED.

Speaking of deprecated -- are the interfaces marked as deprecated in the 6.x
man pages? If not, there's a reasonabl argument to be made that they weren't
deprecated, only eliminated. :-) At this point, in the interest of shipping
working apps, it's sounding like we may need to re-add the interfaces to 7.x
with clear deprecation markings. I'm not sure I'd go for Julian's suggestion
of a sysctl, which simply makes things that should be easy harder for our
users, as opposed to third party developers.

Robert N M Watson
Computer Laboratory
University of Cambridge

> If ye wish to know more, read on.
> Marko Zec wrote:
>> Nobody is questioning the benefits of having RFC 3678 support added to the
>> kernel, but quickly skimming through that document I can't find a line
>> stipulating that it should deprecate older interfaces already in use. What
>> is the exact benefit of deprecating the hack (i.e. RFC 1724
>> compliant ifnet addressing), i.e. why couldn't we have support for both the
>> new and the old interface for legacy applications, given that the
>> interfaces don't seem to be in conflict?

> They aren't mutually exclusive.
> However, sometimes the only way to get people to sit up and take notice about
> the finer things in life is to wave a black flag -- even if this happens 6
> months after something actually occurred -- because I can't compel or use
> force to make anyone to agree with me, so I have to resort to other methods,
> like being irritating to others.
> It is a crusty old hack that creates yet another special case in a bunch of
> kernel code. It gives special meaning to the first eight bits of an IPv4
> address which happen to be zero. It ain't elegant. RFC 1724 was only ever
> intended to be specific to RIP.
> This is just not the right way to support unnumbered interfaces in IPv4. In
> fact, if you look at Linux, they already dealt with this problem by
> implementing scoped IPv4 addresses in-kernel -- too many bits of IPv4 depend
> upon having an address on a link, such as sockets, routing protocols, IGMP,
> hence Stuart Cheshire coming up with RFC 3927.
> Which is why I backported their answer to the problem in the legacy API --
> ip_mreqn. I encourage everyone to look at the patch:
> http://people.freebsd.org/~bms/dump/...sm_phase1.diff
> I draw everyone's attention to the comment re the use of the ip_mreqn
> structure, clearly visible at the top of this patch.
> In short, it needs to go. I realize this is an argument that mostly appeals
> to those who don't follow the Law of Excluded Middle in logic, but, sometimes
> that's the way the cookie crumbles.
> Open source often serves as an example for how to do things, and the code
> that is there is sometimes accepted as gospel, particularly by students, who
> might not always question its wisdom or lack thereof; and this is another
> thing that I'm getting at.
> Of course anything that comes out of my mouth is, mutatis mutandis, subject
> to the same judgement. If I ain't in trouble, I ain't doing my job!
> best,

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"