tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

installing rump libs



Hi,

I've been recently working on getting the rump libs and binaries installed
into the base system.  I've mostly got it done and would like to know
if anyone has any comments.  A diff is here:

http://www.cs.hut.fi/~pooka/NetBSD/rumplibs.diff
(it's not completely finished, e.g. set lists are not yet edited and
it needs some other tweaks also, but I'm interested in comments on the
general structure, not the color (or colour) of my typos)

Since the diff is long and winding and consists very much of moving
files around, here's what it basically does:

* builds rump/fs/lib/lib$yfs as static and dynamic libs and installs them
* builds rump/librump/rump{user,kern} from src/lib/Makefile as static and
  dynamic libs and installs the resulting libraries
* moves sys/rump/fs/bin/* to usr.sbin/puffs.  they are also built and
  installed if MKPUFFS=yes
* moves sys/rump/fs/lib/lib{ukfs,p2k} to src/lib
* adds a sys/rump/fs/rumptest dummy program to check if rump is linkable

What this allows:
* install utilities, possibly even 3rd party ones from pkgsrc, which
  use rump & ukfs.  the most striking example is Arnaud's fs-utils
  which I've already mentioned a few times
* to add some code which will dlopen() the file system libraries instead
  of having to link everything at buildtime - recall, kernel file systems
  are already very modular as is (I have this code already written sans
  some interface meditation)
* use of the kernel file system code in various utilities such as
  fsck and makefs instead of having to rewrite the same code for
  userspace
* preserves the ability to test rump after kernel modificitions without
  having to do a complete release build or have the whole source tree
  lying around

Drawbacks:
* the ABI issue is not very clear.  I'm thinking that rump/ukfs/p2k should
  version themselves according to their own interface ABI and let the
  rump library maintain the compatilibity between librump and lib$yfs
  based on __NetBSD_Version__.  This is much like kernel modules do
  now.  I don't see this causing issues for anyone except people who
  occasionally build and install only half of their userland.
* "duplicates" binaries code from kernel modules.  Eventually it would be
  nice to be able to use the kernel module binary directly, but currently
  the rump build depends on some macro magic to make it work in userspace
  (see sys/rump/include for details).  Solving this might not be entirely
  trivial.


Home | Main Index | Thread Index | Old Index