Allocating AF constants for vendors.

[Alfred Perlstein]

* Bruce M. Simpson <bms at FreeBSD.org> [070903 07:44] wrote:
> Alfred Perlstein wrote:
> >Ok, I'm not really sure what to do here.  At Juniper we have approx
> >20 additional entries for AF_ constants.  We also have theoretical
> >but not practical "problems" with spareness and utility of this
> >list, meaning we have plenty of arrays in our version of ifnets and
> >route entries that are also "bloated" as well.
> >  
> 
> Can you merge them into the list in such a way that AF_MAX does not need 
> to slide forward?
> Or do they need to be referenced from within the kernel tree itself?

They are refenced inside the kernel.

> Prevention of code bloat is better than the cure.  Not having the code 
> in front of me I couldn't say for sure if we're talking about a dozen 
> bytes or several pages potentially being wasted, so it is impossible to 
> judge.

Well, for the most part it's going to be something like 32*sizeof(void*)
so 128 or 256 bytes depending on arch.

> One of my concerns is that we have ifnet.if_afdata, we're not really 
> using it, it makes sense to use it for some things.

I'll have ot look into this.

> Help from big companies as well as little folks is always appreciated, 
> providing we can reach consensus.

YES! :)

> >Otherwise one other policy would be to specify an allocation
> >policy such that new AF_ constants are allocated only for even
> >numbers where odd numbers are left to vendors.
> >
> >This would slow the "bloat" and still provide vendors with something
> >useful.
> >
> >How does that sound?
> >  
> 
> EPARSE? I don't follow this at all.

Ok, let's say we garantee that going forward, all odd AF_ constants 
are verdor reserved....

So whenever FreeBSD allocates an AF constant, it should be even,
vendors can use odd.

That means that, from socket.h:

#define AF_ARP          35
#define AF_BLUETOOTH    36              /* Bluetooth sockets */
#define AF_IEEE80211    37              /* IEEE 802.11 protocol */
#define AF_MAX          38

Now let's say FreeBSD wants to add a AF constant, the next one to allocate
would be 38, so we have:

#define AF_ARP          35
#define AF_BLUETOOTH    36              /* Bluetooth sockets */
#define AF_IEEE80211    37              /* IEEE 802.11 protocol */
#define AF_NEWPROTO1	38		/* some awesome new protocol! */
#define AF_MAX          39

Ok, well that doesn't explain it much, however, shortly thereafter we
allocate another AF constant in FreeBSD, the list now looks like:

#define AF_ARP          35
#define AF_BLUETOOTH    36              /* Bluetooth sockets */
#define AF_IEEE80211    37              /* IEEE 802.11 protocol */
#define AF_NEWPROTO1	38		/* some awesome new protocol! */
#define AF_VENDOR0	39		/* reserved for vendors. */
#define AF_NEWPROTO2	40		/* some awesome new protocol! */
#define AF_MAX          41

Soon another protocol is added:

#define AF_ARP          35
#define AF_BLUETOOTH    36              /* Bluetooth sockets */
#define AF_IEEE80211    37              /* IEEE 802.11 protocol */
#define AF_NEWPROTO1	38		/* some awesome new protocol! */
#define AF_VENDOR0	39		/* reserved for vendors. */
#define AF_NEWPROTO2	40		/* some awesome new protocol! */
#define AF_VENDOR1	41		/* reserved for vendors. */
#define AF_NEWPROTO3	42		/* some awesome new protocol! */
#define AF_MAX          43

As you can see we are defering the "bloat".

Does that make sense?

-- 
- Alfred Perlstein