From owner-freebsd-hackers Tue Jul 20 11:31: 0 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 4D00A152F7 for ; Tue, 20 Jul 1999 11:30:55 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA06200; Tue, 20 Jul 1999 11:30:09 -0700 (PDT) (envelope-from dillon) Date: Tue, 20 Jul 1999 11:30:09 -0700 (PDT) From: Matthew Dillon Message-Id: <199907201830.LAA06200@apollo.backplane.com> To: John Milford Cc: "David E. Cross" , freebsd-hackers@FreeBSD.ORG Subject: Re: USFS (User Space File System) References: <199907201818.LAA19587@soda.CSUA.Berkeley.EDU> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG : :Matthew Dillon wrote: : :> :> No, MFS runs in supervisor mode. That mfs process that you see hanging :> there is just placemarking the VM space. :> :> -Matt :> : : Well, I think there is a little more to it than that. I :believe it does run in supervisor mode, but the mfs process is :providing not just the VM space, but the process context as well. :If I remeber the code correctly, MFS runs as a single process, and :requests are queued (on mfsp->buf_queue) for this process and handled there. : : If the queuing were done a little bit differently, this could :provide a mechanism for returning requests to user space. Something :along the lines of a syscall that enters the kernel and waits for work :as David mentioned before. So instead of having the mfs process handle :the request in supervisor mode, the syscall would return, and the :request could be handled in user mode. It is a little strange, :because the syscall entry and return will be handling different :requests, but I believe it would work. : : : --John 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 Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message