Turning down VFS.

[Dan Cross]

FYI, I mentioned this to Barret, but I'm going to take a stab at getting rid of VFS. Wish me luck.

[Kevin Klues]

I think the plan at some point was to keep the vfs, but make it a
device we attach into the plan9 namespace. Is this still the plan?

On Tue, Oct 6, 2015 at 12:05 PM, Dan Cross <cro...@gmail.com> wrote:
> FYI, I mentioned this to Barret, but I'm going to take a stab at getting rid
> of VFS. Wish me luck.
>

> --
> You received this message because you are subscribed to the Google Groups
> "Akaros" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akaros+un...@googlegroups.com.
> To post to this group, send email to aka...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
~Kevin

[Barret Rhoden]

On 2015-10-06 at 12:07 Kevin Klues <klu...@gmail.com> wrote:
> I think the plan at some point was to keep the vfs, but make it a
> device we attach into the plan9 namespace. Is this still the plan?

There's a lot of parts to removing the VFS, and this was one of them,
depending on how you look at it.

One big part is fixing up #root to be a suitable replacement for KFS.
There are a bunch of things that are wrong with it. From old my notes:

#r has a bunch of issues
- some related to dev genning entries for dirs
- can't rename or do much of anything that the VFS can

#r:
can touch, but time doesn't get set, and mods are messed up.
can chmod to reset them
can attempt to rename, and it also messes up the mods
dirmode check might be busted? or the init dir, convM2D, etc...

i had an email to ron about this, and it has to do with dev genning
fake entries for a directory (no direct entries)

There's probably other stuff too, like not being able to add new
entries easily. For instance, #root uses a fixed array:

struct dirtab roottab[MAXFILE]

Rename is also a beast. We have VFS rename, but not 9ns rename.
There's also the CPIO import utilities (KFS is a CPIO blob attached to
the kernel, initramfs style).

Anyway, making #root or something similar as capable as KFS is a big
part of getting rid of the VFS, since KFS is the only thing we really
use. (I have an ancient half implementation of ext2 that even I don't
use). One of the steps along this route will be to switch over to
using #root and still passing all of the Go tests.

There's a lot more stuff. Another big part is getting mmap working
with Plan 9 devices. That relates to getting the page cache -
something integral in the VFS world but not really a part of the 9ns
world, integrated as something that isn't a "bag on the side."

I have a lot of old notes on this for when the time comes. (Side note,
that was something from Jan 2014, then we got sidetracked with the
Inferno port, then the network stack, then making thing work,
graduating, other priorities, etc).

Yes, having the VFS and 9ns in tandem is ugly. Whether or not we do it
now is more a question of what needs to be done vs what we want to be
done. And no discussion of needs vs wants is complete without a Bob
Dylan reference:

"Your debutante just knows what you need / But I know what you
want"

Barret

[ron minnich]

one thing. You have to make sure you can exec a file from a  file system mounted over devmnt. 

I'm quite sold on the idea of making the vfs a plan 9 device. Then you can mount it. But we still need to figure out the exec picture.

ro

[Barret Rhoden]

On 2015-10-06 at 22:09 ron minnich <rmin...@gmail.com> wrote:
> one thing. You have to make sure you can exec a file from a file
> system mounted over devmnt.
>
> I'm quite sold on the idea of making the vfs a plan 9 device. Then
> you can mount it. But we still need to figure out the exec picture.

Yep. Exec (in our current model) would come with mmap, both .

Another minor thing Dan and I talked about that's also on the VFS
removal list is to use #cons for stdin/stdout/stderr, instead of the
devfs I have attached to the VFS. (Devfs is actually another FS
other than KFS). This won't require getting a full-fledged
console/terminal environment set up; at a minimum we can move over the
existing functions for stdin/stdout to the #cons infrastructure.

One approach for the longer term would be to keep the existing,
somewhat hacky keyboard/console/serial port I/O for the serial, and
then have any decent console stuff just go through userspace and ssh.
The harder alternative would be to try to multiplex good terminal I/O
over the serial port with our existing "early_printk-like" printing.

Though there are a few other tricky points when that comes up, like how
it'd be nice to allow a process to snoop on printks (e.g., devregress's
"monitor" function, kernel logging, etc).

Barret