[Aboriginal] 9p VirtFS for /home

[Rob Landley]

Oh good, I've actually been looking at 9p for a couple months now:

  http://lists.nongnu.org/archive/html/qemu-devel/2011-01/msg02481.html

I just haven't worked out the UI details for adding it to Aboriginal.
(And it's new enough that most distro QEMU versions don't support it yet.)

My local baseconfig-linux has the NFS symbols yanked and the 9p symbols
added, both for the diod tcp server and for virtfs...

On 05/23/2011 01:14 PM, Salman Aljammaz wrote:
> I have a fairly trivial change to share.
> 
> I've modified the init script, the kernel config, and the qemu command
> to mount the host user's $HOME on /home and the host's root on
> /mnt/host on bootup, using 9p [1].  I found this to be easier to work
> with than using an hdb image and FTP.  (The choice of directories to
> export was just for my convenience)

Hmmm...  The problem is that native-build.sh mounts the hdc control
image on /mnt.  (I admit that /mnt/host makes sense, but it's already in
use.)

Read read read.  Think think think...

In root-filesystem, there's a "root" top level directory, added by
commit 1266 as a mount point for the root user's home directory,  (This
is because when you ssh you need a .ssh directory for keys and
known_hosts and such, or else dropbear gets sad.  This mountpoint gives
you some place to slap a tmpfs onto if you need that.)

However, this might also be a great place to mount the root directory of
the host system.  I can just change the passwd entry for root to have
/home/root or such be the home directory of the root user, then creating
and populating it is your problem...

Sound like a plan?

> Caveat: Because this uses VitrIO, this currently only works for x86
> targets.  I believe there was an effort to make that work with ARM as
> well [2] but I don't know what's happened with that.

There's no excuse for virtio NOT to work with other targets, but this
came from KVM rather than QEMU, which means they did a half-assed job
and then stopped, which is SOP for them:

  http://lists.nongnu.org/archive/html/qemu-devel/2011-01/msg02272.html

I'm STILL waiting for decent documentation on virtconsole:

  http://lists.nongnu.org/archive/html/qemu-devel/2011-05/msg00390.html

> Meanwhile we
> could just run a real 9p server (inferno/npfs) and mount it over the
> network.

There's only _one_ that actually works right now with 9p2000.L, and
thats the "Distributed I/O Daemon":

  http://code.google.com/p/diod/

It's undergoing a lot of polishing as the author drops -pre releases
before 1.0 (and as I bitch at him about stuff :), I'd recommend grabbing
the git version.  That's what I'm testing against here.

> I wonder why qemu doesn't do 9p with its user mode network,
> like cifs...  I should look into that.

Exactly.  Before Diod I was poking the qemu guys about genericizing
their infrastructure:

  http://lists.nongnu.org/archive/html/qemu-devel/2011-04/msg00971.html

But then diod came along...

> P.S. Thanks for making aboriginal linux!  I was at the verge of losing
> faith in linux cross compiling; but i discovered this stuff, and it
> actually works!

Thanks.  I'm not a big fan of cross compiling myself, which is why I'm
trying to isolate it.

Unfortunately, I'm running into some limitations.  For example, QEMU
recently grew s390 support but uClibc hasn't got that, so I may need to
add a glibc option for some targets (which has perl as a build
prerequisite, which is too ugly for words)...

Plus I'm stuck on gcc 4.2.1 because the next dot release went GPLv3 and
I only do non-open-source development when paid to, but there's _also_
the fact that 4.3 split out 2 of gcc's subdirectories as separate
packages for no obvious reason, and then gcc 4.5 went "screw it, let's
rewrite the whole thing in C++"...

But 4.2 doesn't support ARMv7 and thumb2, which is kind of important
these days.  Luckily, my layers are orthogonal enough I can build
toolchains with crosstool-ng and slot 'em in.  Unluckily, crosstool is a
flaming pain in the ass to configure and use...

*shrug*  The usual...

 Rob

 1306218544.0