Date: Sat, 22 Jan 2000 13:16:57 +0800 From: Greg Lehey <grog@lemis.com> To: Robert Watson <robert+freebsd@cyrus.watson.org> Cc: Brian Beattie <beattie@aracnet.com>, fs@FreeBSD.ORG Subject: Re: UDF, userfs Message-ID: <20000122131656.C391@mojave.worldwide.lemis.com> In-Reply-To: <Pine.BSF.3.96.1000121184917.66083B-100000@fledge.watson.org>; from robert@cyrus.watson.org on Fri, Jan 21, 2000 at 06:54:15PM -0500 References: <Pine.LNX.4.10.10001211012020.28236-100000@shell1.aracnet.com> <Pine.BSF.3.96.1000121184917.66083B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday, 21 January 2000 at 18:54:15 -0500, Robert Watson wrote: > On Fri, 21 Jan 2000, Brian Beattie wrote: > >> 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. > > Both the Arla and Coda file systems are distributed file systems > managed from userland processes. They do this by providing loadable > kernel modules (or static compiled in code) to allow userland > processes to listen on a device file (/dev/xfsX for Arla, /dev/codaX > for Coda) and receive "upcalls" from the kernel. Usually, the > userland process is multi-threaded so that it can handle in parallel > requests that might involve extensive waiting (for example, > transfering a large file using a network file system). Before > writing something from scratch, you may want to investigate these > and see if they meet your needs. Coda is available in the base > FreeBSD distribution, and Arla as a package. I know that the Arla > project has put significant work into making their code useful > beyond just an AFS client with the intent in mind that other > developers could use the module for other file systems. I built a > fair portion of a caching file system based on the Arla kernel > module at one point. Hmm. A kld runs in kernel context, not user context. Sure, it's easier to load than rebuilding a kernel, and I believe klds are the correct approach to added kernel functionality, but it doesn't offer one of the prime advantages of userland development: if your program crashes, your program crashes, not the system. If you're developing a kld, a bug can crash the system. Still, it might be an answer to my previous message about (now) missing block devices: if we want access to the block devices (which are still there, just no longer accessible from userland), maybe a kld is a good way of implementing them. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers 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?20000122131656.C391>