From owner-freebsd-hackers  Tue Jul 20 12:53:23 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from soda.CSUA.Berkeley.EDU (soda.CSUA.Berkeley.EDU [128.32.43.52])
	by hub.freebsd.org (Postfix) with ESMTP id D060B1519C
	for <freebsd-hackers@FreeBSD.ORG>; Tue, 20 Jul 1999 12:53:18 -0700 (PDT)
	(envelope-from jwm@CSUA.Berkeley.EDU)
Received: from soda.CSUA.Berkeley.EDU (localhost [127.0.0.1]) 
	by soda.CSUA.Berkeley.EDU (8.8.8/) via ESMTP id MAA14190; Tue, 20 Jul 1999 12:52:50 -0700 (PDT)
        env-from (jwm@CSUA.Berkeley.EDU)
Message-Id: <199907201952.MAA14190@soda.CSUA.Berkeley.EDU>
To: Matthew Dillon <dillon@apollo.backplane.com>
Cc: "David E. Cross" <crossd@cs.rpi.edu>, freebsd-hackers@FreeBSD.ORG
Subject: Re: USFS (User Space File System)
In-reply-to: Message from Matthew Dillon <dillon@apollo.backplane.com>
             of "Tue, 20 Jul 1999 11:30:09 PDT."
             <199907201830.LAA06200@apollo.backplane.com>
Date: Tue, 20 Jul 1999 12:52:50 -0700
From: John Milford <jwm@CSUA.Berkeley.EDU>
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Matthew Dillon <dillon@apollo.backplane.com>  wrote:

>
>     This seems like an unnecessary complication to me.  It would be
>     easier to simply make it a device that you can open(), read(), and
>     write() as I first suggested.
>
>     MFS is not a good template for any of this.  MFS is very, very simple
>     and the pieces that would make a user-level device driver work are
>     considerably more complex because they require the ability to make
>     information available to a user process that is usually available only
>     to the kernel.  MFS makes no progress to this end, because MFS runs
>     (more or less permanently) in supervisor mode.
>
> 					-Matt

	I'll defer to you on this as I never got far enough into this
project to have discovered all the complications.

			--John


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message