Allocating AF constants for vendors.

[Max Laier]

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,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20070822/7aca39f0/attachment.pgp