concurrent sysctl implementation

[jt at 0xabadba.be]

John,

     Thank you for your input on this matter, I'm excited to write
some software for this project since its given me great code to learn
from as i've grown up (still a kid though :).  My questions are a bit
more detailed below.

On Mon, May 11, 2009 at 12:24 PM, John Baldwin <jhb at freebsd.org> wrote:
> On Friday 08 May 2009 5:41:17 pm Ed Schouten wrote:
>> A solution would be to solve it as follows:
>>
>> - Use a semaphore, initialized to some insane high value to put an upper
>>   limit on the amount of concurrent sysctl calls. I'm not sure whether
>>   this is really needed. Maybe this issue is not as serious as we think
>>   it is.
>
> Well, one compromise might be to allow concurrent userland requests if the
> buffer size is small (say < 1 page).  This would be a quite simple change and
> would cover many common syscalls like fetching an int which don't wire memory
> anyway.

Why is this a compromise?  Isn't concurrent sysctl calls from userland
a good thing?  What materials would be good to read other than the
code and the sysctl manual pages?  You said it would be relatively
easy to implement this; what methods should I be considering to do
this in and what part of the code specifically should I be looking at?

>
>> - Use an rw/rm/sxlock to protect the sysctl tree, but only pick up
>>   the lock when we traverse parts of the sysctl tree that has
>>   dynamically created entries.
>
> I don't think further work is needed here for the tree, notice that in-kernel
> sysctls are already concurrent and use a read lock on the tree.

yes i've seen the locking mechanism, it reminds me of a monitor type
system... though from my understanding monitors appear seldom compared
to semaphores in the kernel.  I assume the lock will need a bit of
twiddling with in some areas of the code if I'm going to enable
concurrency from userland,  when its said that we should consider the
things that are dynamic would it be better to implement this with more
than one "queue" or list?  Instead perhaps break them up into several
lists or, more fundamentally, two lists -- those that are dynamically
created entries and those that are not -- is this even feasible to
distinguish between the two originally and then on the fly later?

Thanks a lot!

Respectfully,

/jt