svn commit: r280495 - head/sys/kern

Gleb Smirnoff glebius at FreeBSD.org
Wed Mar 25 11:14:36 UTC 2015


On Wed, Mar 25, 2015 at 12:06:46PM +0100, Hans Petter Selasky wrote:
H> On 03/25/15 11:54, Gleb Smirnoff wrote:
H> > On Wed, Mar 25, 2015 at 08:55:35AM +0000, Hans Petter Selasky wrote:
H> > H> Author: hselasky
H> > H> Date: Wed Mar 25 08:55:34 2015
H> > H> New Revision: 280495
H> > H> URL: https://svnweb.freebsd.org/changeset/base/280495
H> > H>
H> > H> Log:
H> > H>   Implement a simple OID number garbage collector. Given the increasing
H> > H>   number of dynamically created and destroyed SYSCTLs during runtime it
H> > H>   is very likely that the current new OID number limit of 0x7fffffff can
H> > H>   be reached. Especially if dynamic OID creation and destruction results
H> > H>   from automatic tests. Additional changes:
H> > H>
H> > H>   - Optimize the typical use case by decrementing the next automatic OID
H> > H>   sequence number instead of incrementing it. This saves searching time
H> > H>   when inserting new OIDs into a fresh parent OID node.
H> > H>
H> > H>   - Add simple check for duplicate non-automatic OID numbers.
H> >
H> > Why didn't you use alloc_unr(9) for that?
H> >
H> 
H> Hi Gleb,
H> 
H> I thought about using alloc_unr(). The problem is that sysctls have no 
H> clear concept of freeing. For example in some existing code sysctl are 
H> unregistered and registered again assuming that the oid_number will be 
H> preserved. I didn't want touch those parts. Also, hence we are already 
H> traversing a list to insert an SYSCTL object in an ordered fashion, the 
H> benefit of alloc_unr() is not that big. What do you think?

Is it possible to split the space into two halves: one for static OIDs and
other for dynamic ones? The latter allocated via alloc_unr?

-- 
Totus tuus, Glebius.


More information about the svn-src-head mailing list