1. 18 Dec, 2015 1 commit
  2. 23 Nov, 2015 1 commit
  3. 20 Nov, 2015 1 commit
  4. 17 Nov, 2015 15 commits
  5. 16 Nov, 2015 4 commits
    • David Johnson's avatar
      Ignorance is bliss. · 5da344d7
      David Johnson authored
      5da344d7
    • Josh Kunz's avatar
      Adds a reference from a cnode its cptr · 83e8ef65
      Josh Kunz authored
              Rationale: When the `revoke` handler is called for a particular
              cspace, cnode, and object, the cptr associated with that cnode
              needs to be free'd so it can be re-used by other objects (given
              there are a relatively small number of cptrs in a cspace).
              We can discover the cptr_cache associated with a cspace by
              looking at the `cspace->owner` field (which we point at our
              cache), but we can't figure out from the cnode alone which
              pointer in that cache points to the given cnode. This
              information is known when the cnode is created, so I added a
              field to the cnode that contains this information.
      83e8ef65
    • Josh Kunz's avatar
      Adds extra documentation to libcap.h · d36af6bc
      Josh Kunz authored
      d36af6bc
    • Josh Kunz's avatar
      Adds a patch that switches from spinlocks to mutexes · 69b6fabe
      Josh Kunz authored
              I don't know about the efficacy of this, I'm sure David used
              spinlocks for a reason, ergo the patch. I got this set of
              #defines from Pankaj.
      69b6fabe
  6. 11 Nov, 2015 1 commit
    • Pankaj Kumar's avatar
      Add hook to lookup/verify cnode in cspace · c6d4015f
      Pankaj Kumar authored
      1. Added a function cap_cnode_verify for cnodes lookup in cspace.
         Earlier cap_cnode_get was called to verify the cnode. It imposed
         extra restrictions on the user of libcap to release cnode lock.
         Now, cap_cnode_verify will itself take care of cnode lock.
      2. Updated testcases to use cap_cnode_verify.
      Signed-off-by: Pankaj Kumar's avatarPankaj Kumar <pankajk@cs.utah.edu>
      c6d4015f
  7. 10 Nov, 2015 2 commits
  8. 04 Nov, 2015 4 commits
  9. 03 Nov, 2015 1 commit
    • 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
  10. 30 Oct, 2015 3 commits
  11. 28 Oct, 2015 1 commit
  12. 23 Oct, 2015 1 commit
  13. 22 Oct, 2015 1 commit
  14. 15 Oct, 2015 2 commits
  15. 14 Oct, 2015 2 commits