From owner-freebsd-fs Sat Jan 22 22: 7:44 2000 Delivered-To: freebsd-fs@freebsd.org Received: from yana.lemis.com (yana.lemis.com [192.109.197.140]) by hub.freebsd.org (Postfix) with ESMTP id EF51715083 for ; Sat, 22 Jan 2000 22:07:31 -0800 (PST) (envelope-from grog@mojave.worldwide.lemis.com) Received: from mojave.worldwide.lemis.com (j39.klt31.jaring.my [161.142.169.233]) by yana.lemis.com (8.8.8/8.8.8) with ESMTP id QAA11619; Sun, 23 Jan 2000 16:36:42 +1030 (CST) (envelope-from grog@mojave.worldwide.lemis.com) Received: (from grog@localhost) by mojave.worldwide.lemis.com (8.9.3/8.9.3) id NAA00455; Sat, 22 Jan 2000 13:16:57 +0800 (SGT) (envelope-from grog) Date: Sat, 22 Jan 2000 13:16:57 +0800 From: Greg Lehey To: Robert Watson Cc: Brian Beattie , fs@FreeBSD.ORG Subject: Re: UDF, userfs Message-ID: <20000122131656.C391@mojave.worldwide.lemis.com> Reply-To: Greg Lehey References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from robert@cyrus.watson.org on Fri, Jan 21, 2000 at 06:54:15PM -0500 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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