take II: Allocating AF constants for vendors.

2007-09-06 Thread Alfred Perlstein
* Alfred Perlstein <[EMAIL PROTECTED]> [070821 14:13] wrote: > Hello all, > > I would like to reserve about 64 entries for VENDOR specific address > families in sys/socket.h. > > I think this will allow vendors to comfortably use the array of > address families without worrying about overlap with

Re: (forw) Re: Allocating AF constants for vendors.

2007-09-06 Thread Bruce M. Simpson
Alfred Perlstein wrote: Bruce, I haven't heard back from you on this. can you please comment? I'd like to add the policy to the header. I'm not 100% happy with this suggestion, however, it is a loosely working compromise. I would be happier if the static index dependency on AF_MAX is ir

(forw) Re: Allocating AF constants for vendors.

2007-09-05 Thread Alfred Perlstein
L PROTECTED]> Cc: Max Laier <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: Allocating AF constants for vendors. Date: Tue, 4 Sep 2007 05:42:24 -0700 Message-ID: <[EMAIL PROTECTED]> User-Agent: Mutt/1.4.2.3i Sender: [EMAIL PROTECTED] * Bruce M. Simpson <[EMAIL PROTECTED]> [07

Re: Allocating AF constants for vendors.

2007-09-04 Thread Randall Stewart
Alfred Perlstein wrote: * Bruce M. Simpson <[EMAIL PROTECTED]> [070904 03:08] wrote: As you can see we are defering the "bloat". Does that make sense? I follow but it still doesn't really make sense. Granted, you are deferring the growth of arrays sized off AF_MAX but only ever by 1 slot.

Re: Allocating AF constants for vendors.

2007-09-04 Thread Alfred Perlstein
* Randall Stewart <[EMAIL PROTECTED]> [070904 13:22] wrote: > Alfred Perlstein wrote: > >* Bruce M. Simpson <[EMAIL PROTECTED]> [070904 03:08] wrote: > > > >>>As you can see we are defering the "bloat". > >>>Does that make sense? > >>> > >> > >>I follow but it still doesn't really make sense. > >>

Re: Allocating AF constants for vendors.

2007-09-04 Thread Alfred Perlstein
* Bruce M. Simpson <[EMAIL PROTECTED]> [070904 03:08] wrote: > >As you can see we are defering the "bloat". > >Does that make sense? > > > > I follow but it still doesn't really make sense. > > Granted, you are deferring the growth of arrays sized off AF_MAX but > only ever by 1 slot. > What i

Re: Allocating AF constants for vendors.

2007-09-04 Thread Bruce M. Simpson
Alfred Perlstein wrote: 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. Let me rephrase that: are protocol domains attached in the kern

Re: Allocating AF constants for vendors.

2007-09-03 Thread Alfred Perlstein
* Bruce M. Simpson <[EMAIL PROTECTED]> [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 > >l

Re: Allocating AF constants for vendors.

2007-09-03 Thread Bruce M. Simpson
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

Re: Allocating AF constants for vendors.

2007-09-02 Thread Alfred Perlstein
* Bruce M. Simpson <[EMAIL PROTECTED]> [070822 07:33] wrote: > I second Max. If you are going to introduce a bunch of AF_* constants > into the tree you have to be very careful as AF_MAX is used to size > arrays and figure out how many radix trie heads to allocate. Ok, I'm not really sure what to

Re: Allocating AF constants for vendors.

2007-09-01 Thread Alfred Perlstein
* Max Laier <[EMAIL PROTECTED]> [070822 14:38] wrote: > On Wednesday 22 August 2007, Bruce M. Simpson wrote: > [...] > > On the other hand, if you don't need to reference these constants in > > the kernel at all, and they will all exist beyond AF_MAX, then you can > > disregard what I've said and a

Re: Allocating AF constants for vendors.

2007-08-22 Thread Max Laier
On Wednesday 22 August 2007, Bruce M. Simpson wrote: [...] > On the other hand, if you don't need to reference these constants in > the kernel at all, and they will all exist beyond AF_MAX, then you can > disregard what I've said and append them to the rest of the list. Please make sure to leave a

Re: Allocating AF constants for vendors.

2007-08-22 Thread Bruce M. Simpson
I second Max. If you are going to introduce a bunch of AF_* constants into the tree you have to be very careful as AF_MAX is used to size arrays and figure out how many radix trie heads to allocate. It could be argued this wastes a bunch of CPU time and memory, though I speculate 'not much' at

Re: Allocating AF constants for vendors.

2007-08-21 Thread Christian S.J. Peron
Can you please submit your patch to the group for review? On Tue, Aug 21, 2007 at 01:50:55PM -0700, Alfred Perlstein wrote: > Hello all, > > I would like to reserve about 64 entries for VENDOR specific address > families in sys/socket.h. > > I think this will allow vendors to comfortably use the

Re: Allocating AF constants for vendors.

2007-08-21 Thread 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 anoth

Re: Allocating AF constants for vendors.

2007-08-21 Thread Alfred Perlstein
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 s

Allocating AF constants for vendors.

2007-08-21 Thread Alfred Perlstein
Hello all, I would like to reserve about 64 entries for VENDOR specific address families in sys/socket.h. I think this will allow vendors to comfortably use the array of address families without worrying about overlap with FreeBSD protocols. If no one objects I plan to commit this in the next fe