>> >> and then you have all the mappings for name<->number under net.  for
>> >> the children of those nodes, you simply iterate.
>> >
>> >What happens if the name<->number mappings change in between the 
>> >mapping call and the walking?  It's dynamic, so you're going to have to 
>> >expect this.
>> 
>> good question.
>> 
>> the answer is that each node has a version number (an int -- i am
>> studiously ignoring the case where the version number wraps around).
>> 
>> when a node is created the global version counter is incremented and
>> the new version number is assigned to the new node and its parent,
>> straight up to the root of the tree.
>> 
>> likewise, when a node is destroyed, the global version number is
>> incremented, and the new version number is assigned to the parent of
>> the node that is being destroyed all the way back up the tree.
>> 
>> sysctlnametomib() just checks that all the versions are the same at
>> the top of the tree each time it's called, and for those that have
>> changed, it purges that data from its cache.
>
>It seems like sysctlnametomib() still races the kernel to lookup the
>next name<->number mapping before the previous name<->number mapping
>is changed/deleted.

not really, no.  sysctlnametomib() just asks the kernel what the top
level looks like and uses it to refresh its cache.

>It sounds like sysctlnametomib() can catch that by comparing the version
>number at the top of the tree before the lookup with the version after
>the lookup, and then either restart the lookup or return -1 (EBUSY?).
>So far, so good.

um...what?  sysctlnametomib() just (calls an internal function that)
refreshes the top level of its cache once each time it's called.
after that, it translates each token in the string you gave it to
numbers.

if the mapping changed before you called sysctlnametomib(), during,
and after, you can't find out the mapping, but if the value is that
transient, what good is it to you?

>Whether or not sysctlnametomib() restarts or returns -1 if an add/delete
>invalidates the path, I am concerned that there is no guarantee that a
>process will make any progress resolving any name if, say, the kernel
>is rapidly adding/deleting nodes virtually anywhere in the tree. The
>kernel might do that even in non-pathological cases.

sysctlnametomib() doesn't restart, but it might return -1 if any of
the names you gave isn't found.  if the name was there five minutes
ago, disappeared for a second, and came back, the data to which it
refers may (or may not) be the same as the data you were looking for.

would you rather get stale/wrong data, or an error indicating that the
thing you were looking for is no longer there?

>I think I am probably just missing something.

how often do you think nodes will be added to (or removed from) the
tree?  i figured on four generic "times":

	when the kernel boots (autoconfig has not yet happened)
	during autoconfig or when a new device is detected
	by an lkm when its loaded
	by a process

what were you thinking of?

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
werdna@squooshy.com       * "information is power -- share the wealth."