On Wednesday 22 August 2007, Alfred Perlstein wrote: > I trimmed the sender of this because I got it in private mail, that > said I thought it was a good bunch of questions so I am replying > to it. > > > 64? are you intending to bump AF_MAX or allocate them sequentially > > such that adding another AF will require AF_MAX to grow a lot? > > > > In general this seems like a bad idea to me. I suggest you need to > > (publicly) explain what you are doing and why this is a good idea. > > The goal here is to allow vendors to add their own constants without > worrying about conflicting with FreeBSD constants. It will allow > vendors to maintain some semblance of binary compatibility against > FreeBSD. > > If you look at libpcap: > > http://cvs.tcpdump.org/cgi-bin/cvsweb/libpcap/pcap/bpf.h?rev=1.15 > > You can see that Juniper has asked for some number of reserved > "families", in our case, I think it would be a bit greedy to > grow the list _just_ for Juniper, so I suggested something that > would work for every vendor. > > As far as implementation details, either one works for me, do you > have any particular preference? > > Other than the actual delta, will this have any noticeable negative > impact that you can see?
DLTs are something very different to address families. DLTs are cheap as they are simply a number that is passed around. In contrast to that, there are some AF_MAX sized arrays in the kernel (e.g. if_afdata[] in struct ifnet or the routing tables) these will grow if you change AF_MAX - that's a bad thing! Could you provide a patch with what you have in mind so I (and other similarly confused people) can understand what you have in mind. Extending AF_MAX by 64 is out of the question, IMHO. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News
signature.asc
Description: This is a digitally signed message part.
