Date: Sat, 22 Jan 2000 01:57:07 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: beattie@aracnet.com (Brian Beattie) Cc: fs@FreeBSD.ORG Subject: Re: UDF, userfs Message-ID: <200001220157.SAA25999@usr09.primenet.com> In-Reply-To: <Pine.LNX.4.10.10001211012020.28236-100000@shell1.aracnet.com> from "Brian Beattie" at Jan 21, 2000 10:19:36 AM
next in thread | previous in thread | raw e-mail | index | archive | help
> I have made a couple of posts to hackers, that probably should have gone
> here to fs. I and thinking about implementing a UDF filesystem. The plan
> I am considering, is to implement a "userfs" to allow me to do most of the
> work in a user process.
>
> I have been thinking about the userfs implementation. I will need some
> way for the user process to talk the backend of the userfs kernel code.
> The two ways I have thought of are I/O,, probably ioctl's or a new system
> call.
>
> I assume that it is possible, using a module to add an entry to the
> syscall table, but I lean more towards a new pseudo device to hang the
> ioctl's off of.
>
> I would be ineterested in any comments. I would also like to hear from
> anybody who has thought about a userfs implementation for FreeBSD.
The Apple people have already implemented one of these. The main
problem is that you have to access part of the disk in ISO9660 mode,
and part of it in raw mode. This is a problem in the current FreeBSD
because the Apple people used one mount on the character device and
one on the block device to accomplish this magic.
Effectively, you will probably need to define a new slicing
mechanism, to sit at a level equal to the DOS partitioning,
extended parititioning, and the BSD disklabel to get around
the inability to do this any more. This would require non-userspace
work, but it would work rather well.
As far as proxying into user space for FS developement, there is
still a coherency problem. You will need to use the VOP_READ and
VOP_WRITE to implement VOP_GETPAGES and VOP_PUTPAGES in order to
get around this. See the hacked up NULLFS that was posted about
to the FreeBSD-FS list as a means of getting around the kernel
VFS and vmobject_t brain damage.
You could try to modify "amd" or a similar user space NFS server
to push the data, but for DVD, I think the data rate you would
see doing this would be terrible.
As an alternative, I'd suggest maybe developing it in user space,
but expecting to deploy it in kernel space. This is not really
as hard as it sounds, if you buy into the slice handler for
seperating the ISO9660 and non-ISO9660 data on the disk.
As far as the proxy itself, I suggest a "tun" or "bpf" style
pseudodevice, since it has worked well for me in the past. The
trick is that the VOP's are all passed around as descriptors,
and they are opaque to crossing user/kernel boundaries. You
will need to be able to lock down the references, if you intend
to access them via /dev/kmem. Instead, I suggest, you mmap()
the device into your process address space, and access it that
way, since it greatly simplifies the faulting.
In terms of proxying VOPs across an opaque boundary, you should
read John Heidemann's master's thesis from the FICUS project out
of UCLA; it is available at ftp.cs.ucla.edu; if you need a better
URL, I can find it for you. It was intended to support proxy of
data over a network, but the principle extends to any opaque
boundary crossing, where the address space is not the same on
both sides of the boundary. This will also show you why the
FreeBSD implemetnations of VOP_READ, VOP_WRITE, VOP_{GET|PUT}PAGES,
and VOP_READDIR (cookies) are currently broken.
You will have to hack the mount stuff to access through either
a seperate psuedodevice, or some form of covert channel on the
same pseudo device. The way I personally handle it is to
collapse all the mount code, and seperate it into to VFS_ routines
(VFS_MOUNT, VFS_SETINFO), and move all of the code that can
differentiate between root and non-root mounts to higher level
code (this lets me do things like boot with a UMSDOS layer
stacked over an MSDOS layer as my root filesystem, for example).
Then I start my user space server, and use two pseudo devices,
/dev/vfs0 and /dev/vfs0vop. The VFS ops are proxied over the
first, the VOPs over the second. Then the mount can proceed.
If no one has the /dev/vfs0 open, the mount attempt fails.
Hope this helps, and hope you can get your code for it back into
the tree.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001220157.SAA25999>