Re: CVS commit: src/tests/net/icmp

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

On Thu Jul 08 2010 at 23:22:44 +0200, Thomas Klausner wrote:
> [redirected from source-changes-d to a hopefully more suitable mailing
> list]
> 
> On Mon, Jul 05, 2010 at 12:26:17AM +0300, Antti Kantee wrote:
> > I'm happy to give a more detailed explanation on how it works, but I need
> > one or two questions to determine the place where I should start from.
> > I'm planning a short article on the unique advantages of rump in kernel
> > testing (four advantages by my counts so far), and some questions now
> > might even help me write that one about what people want to read instead
> > of what I guess they'd want to read.
> 
> I looked at the tests some more (tmpfs race, and the interface one
> from above). I think I can read them, but am unclear on some of the
> basic properties of a rump kernel.

Hi, good questions.

> For example:
> 1. Where is '/'? Does it have any relation to the host systems '/'? Is
> it completely virtual in the memory of the rump kernel?

From a practical perspective, it's in the same place as '/' on e.g.
a qemu instance or xen domu: "somewhere".  By default it's in memory,
but you can mount any file system as '/' over rumpfs (default rootfs).

Of course this is partially a trick question, since a rump kernel does
not necessarily have a '/' at all.  Running a configuration without file
systems at all can save quite a bit of memory, and can be the difference
between 50k and 100k nodes in a virtual netowrk (I've only tested up
to a few hundred nodes on my scrawny laptop, but I've done calculations
... I'm sure you can appreciate calculations ;).  In that case any rump
system calls attempting to use VFS will fail with ENOSYS.

> 2. Do I understand correctly that for e.g. copying a file from the
> host file system into a rump kernel file system, I would use read and
> rump_sys_write?

Well, yes and no.  It depends on which namespace you are making the
calls from.  If you are in the host namespace (i.e. not inside the rump
kernel), you can do that.  The paths given to rump_sys_open() are ones
relative to the rump kernel '/' (or whatever you've chrooted to inside
the rump kernel), and then you just use the file descriptor as usual.

If you are inside the rump kernel, you can access the host file system
namespace with "etfs", extra terrestrial file system, with which you can
establish mappings from the rump kernel namespace to the host namespace.
For example, the rump_foofs utils use this to configure a virtual block
device pointing to the host, so when I type

        rump_ffs /home/pooka/ffs.img /mount

even though VFS_MOUNT() operates inside the rump kernel, the device file
for mount is still use from the host (and, etfs can also just report it
as a block device, so you don't need any of the vnconfig nonsense).

> 3. Similarly for network interfaces -- open a socket with socket(2) or
> rump_socket(or so) and copy bytes with read/rump_sys_write?

I'm not quite sure what you want to copy from and where.  If you
connect() to a network service inside the rump kernel, you access it
from the host with read/write (or send/recv) just like any other peer.
If you rump_sys_connect(), you use rump_sys_read/rump_sys_write().

I probably should point out that rump has two different networking
configurations: a full networking stack and what I call "sockin".
The prior is exactly what you'd expect: interface, tcp/ip, sockets and a
unique IP (or other) address.  This can be a hassle sometimes when you
want to use networking from the rump kernel and do not have a separate
IP address or simply just don't have root privileges to configure a
tap interface.  sockin registers at the protocol layer in the kernel
and pretends to be an inet domain.  What it does is just maps requests
to the host sockets.  So e.g. PRU_CONNECT does connect() _on the host_.
This is helpful for cases where you need networking (e.g. rump_nfs and
rump_smbfs), but do not want to hassle and administrative boundary of
configuring a separate address.

> 4. Could you NFS export the rump kernel file system to the host?
> (Probably better to a second rump kernel...)

Yes.  When I make changes which affect nfs, I test them by running one
rump kernel with the nfs server and one instance of rump_nfs (the latter
using sockin, i.e. effectively the rump kernel nfs exports to the host).
This way I get a two-machine illusion -- naturally, since the nfs client
is quite finicky, I don't want to use mount_nfs for testing on my desktop.

nfs itself presents one of the unsolved issues with rump: the division
between rump kernel and host kernel is done at the syscall level: foo
or rump_sys_foo().  However, for libraries "foo" is already hardcoded.
This is especially problematic for libc, since even LD_PRELOAD will not
help.  There's a few different things I've been playing around with this,
but will try to detour into verbose explanations of them in this email.
The whole issue is explained here (and generally in the thread):
http://mail-index.netbsd.org/tech-kern/2009/10/16/msg006276.html

The above also contains instructions on how to use rump nfsd.  Notably,
these days you do not need to build the nfs server component on i386,
but you can use the kernel module readily available from /stand instead.

For those with a high threshold for pain, let's review that my first
version for nfsd inside a rump kernel used a forked puffs null mount
to access the host file system namespace to be able to export it.
(if that didn't make any sense, don't worry.  it didn't make sense to
me either ... but it worked ;).

Now the default requires to serve the file system from inside the rump
kernel namespace.  This, of course, can be from an image on the host if
etfs is used.

> 5. I think I read that rump (or some other part) can now talk USB. How
> would one attach a USB device on the host system to a USB controller
> inside the rump kernel?

It works by probing the host /dev/ugen{0...n} and faking a host controller
if it is able to open the device.  The kernel USB stack then operates
on the rump-faked host controller as it would, and the host controller
proxies the requests to /dev/ugen.  The whole thing was pretty much the
topic of my AsiaBSDCon paper this year.

There is no other magic than rumpusbhc<n> probes /dev/ugen<n>.
Plenty of examples for different USB device drivers are present in
src/share/examples/rump.

> Is that a good start for questions? :)

yes.  hopefully i did even half as well in answering them.

  - antti