Re: quota(1) & friends for rump ?

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Wed Jan 12 2011 at 19:08:03 +0100, Manuel Bouyer wrote:
> Hello,
> I've been working on a new quota system for ufs, and I'm to the point where
> I need to run quota/edquota/repquota/etc againt my kernel code.
> I'm using rump_ffs (& atf) for this work and I'd like to be able to 
> send quotactl ioctls to the rump kernel.
> How is it done ? Is it possible to use the standart quota tools against
> a rump kernel (this way, I can test both kernel code and the tools at the
> same time) ?

Hi,

short answer: yes
(but keep reading ;)

I'll explain some background first just to make sure everyone following
this discussion is on the same page.  rump_ffs starts a rump kernel inside
a process, mounts the file system in that process and then uses puffs to
attach that process to the host's fs namespace.  This makes the mount
seem like any other kernel mount, but at the "price" of requests being
routed to the file server via the host kernel and puffs.  This works
fine for everything as long as the operations used by vfs/puffs are
somewhat stable.

Now, puffs does not support the quota operations.  I started adding them
a long time ago, but came to the conclusion that properly supporting them
would require a complete rework of the quota calls, and never pursued it.
(I'm glad someone is taking care of the quota calls now ;).  You could add
support for those as part of your work and even test puffs completely in
userspace, but I assume there would still be some iteration and that means
waiting for reboots and that's very frustrating.  And, if you're like me,
you like working on one problem at a time instead of several.  So, you
can't easily use the fully transparent option for this particular work.

Recently, I started adding rump client support for some select base system
utilities.  They work by calling the rump kernel directly over a socket,
and all host kernel interfaces are skipped.  The policy of what to call
is in the application and syscalls are passed to rump_sp(3) for delivery
to the kernel.  Since apart from quotactl() vs. rump_sys_quotactl() the
application works the same (or whatever proplisty things you're going to
come up with), mods are very easy.  Notably, people not interested in the
functionality have felt unbearable aesthetic discomfort with the approach,
but if you are interested in using the functionality to make your life
easier, maybe like me you'll find that bitter pill easier to swallow.

Even with that, there are still two hurdles:

1) you need to mount the file system you want to test quota on
2) you need to access the file system with the right credentials -- i
   assume for quota you want to test non-root users

For "1" there is some nice support by Arnaud Ysmal as part of his
GSoC projects.  Unfortunately, that isn't in the tree yet, so it will
not help you directly.  However, in testing context you can reuse
code from Nicolas Joly's excellent fs-independent testing framework.
What you basically want to do is to come up with a simple rump server
which mounts the file system under test to, say, /test and daemonizes.
This is just a few lines of code.

I haven't attacked unpriv'd clients yet, but there are hooks for that in
the rump_sp code, so I should be able to add some support quite quickly
if you decide you want it.  Then the usage would be something like:

env RUMP_UID=1323 dd if=/dev/zero rof=/test/file bs=n count=x
(better suggestions accepted)
(and the dd usage will probably change, but i can drop you a separate
note when that happens)

And check if you get an error when expected.

There are a number of tests which contain examples on how to start
kernel servers and how to talk to them.  E.g. cgd, md, raidframe and
sysmon in tests/dev do this.  md might be interesting, since it uses a
custom server.

Finally, getting back to thinking about rump_ffs, taking the above into
account, you maybe could be able to make rump_ffs open a rump_sp(3)
server in addition to attaching to puffs, do the quota*(8) calls purely
in userspace and all other fs access via puffs.  However, I don't
generally like tests which assume host kernel support, especially if
the pure-userspace alternative is just as convenient.  So, I'd take the
approach I presented first.

> BTW, rump and atf are really wonderfull for this kind of work. kudos
> to the peoples who made it possible !

I'm not sure if what I presented sounds complicated, but with a few minute
to few hour investment (depending on prior experience with the tools)
you'll have a fully userspace development rig and post commit you'll be
pretty much guaranteed that no expected breakage happens in the future,
no matter what rototills hit the tree.

-- 
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa