Re: VFS questions

Bryn Paul Arnold Jones (bpaj@gytha.demon.co.uk)
Wed, 30 Apr 1997 19:30:01 +0100 (BST)


On Wed, 30 Apr 1997, Jon Peatfield wrote:

> I'm not a kernel expert. (I thought I better say this before anything
> else).
>
> I would like to write a very simple file-system (lofs) which acts like
> lofs on sunos etc. This mounts one directory onto another.
>
> The current vfs layer doesn't seem to pass the name (or inode) I need
> though to the fs specific read_super(). i.e. for fs needing devs it
> passes the device number, and for nodev devices it passes a "new
> device" number, but there isn't any way to say that a fs needs a
> directory (not a device) as the device.
>
> In my current mockup I'm passing the directory through in the options
> data, but this isn't very clean.
>
> Would any other file-system ever need a directory as the "device"? If
> so I can make some changes to fs/super.c to accomodate it. I don't
> want to make changes just for one file-system though since I can fake
> things for now.
>

Hmm, the loop back device solved this by having a losetup (now
incorporated in mount) that "attaches" a file to a block device (ie it
tells the kernel /dev/loop0 is /wherever/somefile). Then when the
mount(2) comes in, it's all sorted.

> My other question is why isn't _namei() (or dir_namei()) available
> outside namei.c? In my case the name of the directory to lookup is
> already in kernel space, so namei() fails (-EFAULT). I think I'll
> need to use open_namei() which is overkill for what I need...
>

Can't help you with this.

> Now is a very good time to tell me if someone else has already got a
> working lofs :-)
>

Hmm, this seems to me incredibly like unionfs/ufs/ifs (last two may be
confusing, but the ones I mean are the same as unionfs). If it is, I know
this it has been discussed, tried, and given up on several times; not that
I want to put you off or anything ;).

> --
> Jon Peatfield, DAMTP, Computer Officer, University of Cambridge
> Telephone: +44 1223 3 37852 Mail: J.S.Peatfield@damtp.cam.ac.uk
>
Bryn

--
PGP key pass phrase forgotten,   \ Overload -- core meltdown sequence 
again :( and I don't care ;)      |            initiated.
                                 / This space is intentionally left   
                                |  blank, apart from this text ;-)
                                 \____________________________________