Skip to content
  • David Johnson's avatar
    Refactor libcap to allow both user lib and kernel module builds. · ab9ac0a0
    David Johnson authored
    Mostly, I kept the existing source skeletons in cap.c and
    cptr_cache.c (they've just moved to src/common), but all the
    user/kernel include differences are nicely factored out.  You
    might think my organization is a bit schizophrenic (a flattened
    include/ dir, and a hierarchical src/ dir), but I do that because
    I don't particularly care for libraries that install headers in
    $PREFIX/include/libfoo/{subdir1,subdir2,...}.  The idea with the
    src/ dir is that common cap/cptr logic goes in src/common, and
    any "platform" specialization (user lib vs kernel mod) goes in
    src/user or src/kernel .  The libcap.h and libcap_internal.h
    headers define some common types, macros, and functions, and expect
    the platform headers and source files to specialize them.
    
    I added a very basic notion of capability object types and tied it
    to revocation and deletion in the same way the original library did.
    
    For userspace, since I didn't have atomic ops, I just did basically
    what the kernel does, a cache-aware spinlock thing, but used pthread
    spinlocks (what does that even mean) in hopes they could do something
    smart internally.  Silly me, glib actually has atomic ops.  Anyway, I
    had to do that to restore atomic bit ops to userspace.
    
    Obviously, I got rid of all the LCD-specific stuff.
    
    Most of the build happens via automake, but you'll notice the
    src/kernel/Makefile.in .  That's not a checkin mistake; the kernel
    build makefiles don't play nicely with autofoo.  That Makefile just
    calls into the kernel module build process in the normal way.  Of
    course, we have to do some autofoo to arrange the sources and the
    Makefile to be in the same dir... stinky.  See src/kernel/Makefile.in .
    
    For now, we haven't committed the generated .in files; use
    autogen.sh as described in INSTALL.  That will probably change
    down the road.
    
    I mostly left the examples unchanged, although I added some locking
    to the multithread example and abstracted out its thread operations
    so you're not locked into 20k threads; it scales.  I also tried to
    make the grant/revoke operations wait until the slots had been
    constructed.  This extra locking and care has the effect of
    reducing the paralellism, I suppose, but not enough to detract from
    the test, I think.  We'll see.
    ab9ac0a0