1. 19 Jan, 2016 1 commit
    • Charlie Jacobsen's avatar
      Add kernel build fixes. · d6dc6cb7
      Charlie Jacobsen authored
      I got rid of the KERNEL_HEADERS_INSTALL thing. Kind of silly. The
      user is just expected to set their prefix right. We still have to
      do a hook in order to install the kernel-specific stuff. libcap.a
      and libcap.ko (kernel binaries) go in prefix/lib.
  2. 17 Jan, 2016 3 commits
    • Charlie Jacobsen's avatar
      private-types: Adds struct cap_type_system. Old code builds. · 24491621
      Charlie Jacobsen authored
      The code builds right now by default (--enable-global-cap-types is
      on by default). Next step is to adjust the internals.
      Fixed an autoconf script bug: if you AC_SUBST a variable in one
      case and AC_SUBST_FILE in another (perhaps in an if statement), autoconf
      gets confused. So, I just always AC_SUBST now and cat the file into
      the variable when necessary. (I'm referring to the
      CAP_INCLUDE_GLOBAL_TYPES variable in configure.ac.)
    • Charlie Jacobsen's avatar
      private-types: Updates headers and build for private type systems. · b5dc70da
      Charlie Jacobsen authored
      This will not build yet (cap_type_system_t not defined yet).
      In LCDs (kernel land), there will be multiple threads sharing
      this library, but they shouldn't share the same set of types. So,
      we need to allow building libcap to preclude this sharing (using
      a global type system).
      A global type system is allowed by default, and the same interface
      will still be there if global types are enabled. There are a few
      new functions introduced with this new feature:
      These functions will now always be part of the interface. The old
      functions will be available if global types are allowed:
            cap_init_cspace - init cspace and attach global type system to it
            cap_register_type - register a global type
      I used some autoconf magic to conditionally include these old
      functions in the libcap.h interface.
      Implementation not in place yet.
    • Charlie Jacobsen's avatar
      Updates cptr cache defs and build so that cspace config can truly vary. · 40077300
      Charlie Jacobsen authored
      Before, I just had some CPP checks that would stop the build
      if the cspace depth wasn't 4, etc. So it required some manual
      changes. Now it should be fully automated.
      There are three awk scripts that generate some C code / do some
      calculations, and the results are plugged into some headers (that
      are now templates and generated by configure). I did it this way
      because the CPP doesn't seem powerful enough to generate variable
      length definitions like this (without some serious CPP hacking).
      Easier to use awk and then AC_SUBST the results in.
      If we want to make the code even faster, we could precompute some
      other stuff like this as well.
      I tested the user build, and ran multi_thrd_cap with a cspace
      depth of 8, and cnode table size of 8. Looked ok.
  3. 16 Jan, 2016 4 commits
  4. 15 Jan, 2016 6 commits
    • Charlie Jacobsen's avatar
    • David Johnson's avatar
      A last piece of the hack to work around config.h in public headers. · bfea6263
      David Johnson authored
      This is sick.  I should have just reorg'd the headers.  This should be
      baked out ASAP.  It elides the core libcap_config.h conflicts to allow
      multi-package-config.h includes.  autofoo doesn't help at all with this,
      but why should they?  Shouldn't include config.h in public stuff.
      This is the same commit as I did for openmul.  That one was defensible
      (way too much code to reorg the headers); this one, not so much... but I
      don't have time to reorganize the headers.  Here's basically the same
      commit msg to explain things:
          Every time you think you've reached a new low with autotools, you're
          wrong.  This is my way to get around the standard installable
          config.h problem.
          Basically, libcap wants you to include headers that require config.h,
          but of course things that use libcap have config.h of their own.  So --
          we take the hacky approach and remove the things that will obviously
          conflict and stick them in mul_config_internal.h .  I'm sure my way
          of doing this will be missed if config.status include/libcap_config.h is
          ever run to regen libcap_config.h, but I can't solve that one right
    • David Johnson's avatar
      Move to using a prefixed config.h . · 08d889b3
      David Johnson authored
      This library has consumers that build against its installed
      version.  For that, and for the other general problems that
      including config.h in public headers causes, just make config.h be
      prefixed so it is "unique" and install that one.
      It was either this, or hack the headers once again with some
      foo like that).  But let's not do that now... the headers need a reorg
      before something like that happens.
    • Charlie Jacobsen's avatar
      reorganize: Updates configure script for cspace configuration. · e7786bf6
      Charlie Jacobsen authored
      Tested configure script, but not build yet.
    • Charlie Jacobsen's avatar
      reorganize: Updates most of public headers, not tested yet. · ba42c87a
      Charlie Jacobsen authored
      configure.ac has some garbage code in it to remind me to
      add the cspace config stuff.
    • Charlie Jacobsen's avatar
      reorganize: Configure script runs without error. · 515c5a94
      Charlie Jacobsen authored
      For both platform targets -- user and kernel.
  5. 14 Jan, 2016 2 commits
  6. 11 Jan, 2016 1 commit
    • Charlie Jacobsen's avatar
      static-cptr-cache: Adds lock to cptr cache, fixes race conditions in tests. · 8c39cffc
      Charlie Jacobsen authored
      All looks OK now.
      Few other misc things:
         - config.h header goes with install
         - Some debug code in cap.c.
         - Wasn't handling return value of make cnode table in cap.c.
      For now, until we (possibly) move stuff around, I'm including the
      internal header in the public header so that I have access to
      the cap mutex type. I'm considering re-working things so that this
      won't be necessary in the future. Temporary hack for now.
  7. 10 Jan, 2016 1 commit
    • Charlie Jacobsen's avatar
      static-cptr-cache: Changes cptr cache defs to use statically alloc'd bmaps. · 48ee0d11
      Charlie Jacobsen authored
      That is, the bitmaps are now arrays inside the cptr cache, rather
      than pointers. We need this for LCDs because the cptr cache needs
      to be up and running before we even initialize the page allocator
      and malloc.
      I need to tweak the code slightly next.
      Note: I considered using a packed struct for cptr's, with char
      fields. But I realized the allocation algorithm would become a little
      less efficient, due to extra required calculations. The advantage of
      the current algorithm is that, because the cnode table size is
      a power of 2 *and* the bits are packed (they would no longer be
      packed if we used chars, unless the cnode table size was 512), translating
      a bitmap index to a path in the cspace radix tree is really simple.
      If we switched to a struct with char's, such as:
          struct cptr {
             char level;
             char path[CAP_CSPACE_DEPTH];
             char slot;
      we would need to do a handful of bit shifts and masks to set up
      these fields properly. (For the current algorithm, there's just
      one bitwise OR to set the level bits.)
      I also realized the bit-level ops we currently use are not that
      bad/obscure. We just sacrifice a slight amount of clarity.
  8. 04 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.