> 1) Modify the Linux kernel to present a 9P interface to itself (too
> hard, almost like re-writing several important parts of the kernel)
> 2) Modify the Plan 9 userspace to work with POSIX (Yuck, and Plan9Port
> already does this)
> 3) Create a custom INIT process which will be responsible for providing
> all the "plan 9 kernelish" features that userspace programs expect (for
> eg. providing the /net directory), so that all of them can run unmodified.
As Forsyth says, this may not be such a great final-year project,
especially if you have only two months in which to do the work.
That said again, I don't think any of the three strategies above would
really make Linux feel like Plan 9. For example, I should be able to
"9fs sources" and then run the Unix ls or the Gnome file browser
or whatever on /n/sources and have it work.
To really make it feel like Plan 9, you'd first want to write a binary
format driver (in Linux) for Plan 9's a.out binaries. Then you can
load Plan 9 binaries directly. That much is pretty simple.
Next, you'd want to implement the Plan 9 system calls as an "alternate
personality" for the Linux kernel, to be used when running the Plan 9
binaries. Some of the system calls are fairly easy -- open, read, write,
close, stat, wstat -- but bind / mount will require:
- per-process name spaces accessible to normal users
(CLONE_NEWNS is only available to root, but you can
probably reuse some or all of the code)
- letting normal users do 9p mounts anywhere in their
own name space (can probably use v9fs here)
Also rfork, notes, etc. will require a little bit of work,
but they're straightforward.
Once you've got that, then the icing on the cake would be doing
things like writing a /net for Linux and then rewriting the socket
calls to do user space file operations on /net. Then you could
do things like
import othermachine /net
firefox
Also the missing /proc files and so on.
Russ
