Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Aug 2007 02:02:17 +0200
From:      Max Laier <max@love2party.net>
To:        freebsd-net@freebsd.org
Cc:        Alfred Perlstein <alfred@freebsd.org>
Subject:   Re: Allocating AF constants for vendors.
Message-ID:  <200708220202.23004.max@love2party.net>
In-Reply-To: <20070821232956.GT87451@elvis.mu.org>
References:  <20070821232956.GT87451@elvis.mu.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1348266.DDDgb8NVuj
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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=3D1.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=20
they are simply a number that is passed around.  In contrast to that,=20
there are some AF_MAX sized arrays in the kernel (e.g. if_afdata[] in=20
struct ifnet or the routing tables) these will grow if you change=20
AF_MAX - that's a bad thing!

Could you provide a patch with what you have in mind so I (and other=20
similarly confused people) can understand what you have in mind.

Extending AF_MAX by 64 is out of the question, IMHO.

=2D-=20
/"\  Best regards,                      | mlaier@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

--nextPart1348266.DDDgb8NVuj
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQBGy30OXyyEoT62BG0RAjmMAJ0YXaeodrXZxB4UJ0Q2TIP87aKxGACfU0WT
H2U6yTwii28tYwucnk1OfWs=
=g2Na
-----END PGP SIGNATURE-----

--nextPart1348266.DDDgb8NVuj--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200708220202.23004.max>