-
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