Date: Tue, 20 Jul 1999 11:30:09 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Milford <jwm@CSUA.Berkeley.EDU> Cc: "David E. Cross" <crossd@cs.rpi.edu>, freebsd-hackers@FreeBSD.ORG Subject: Re: USFS (User Space File System) Message-ID: <199907201830.LAA06200@apollo.backplane.com> References: <199907201818.LAA19587@soda.CSUA.Berkeley.EDU>
index | next in thread | previous in thread | raw e-mail
:
:Matthew Dillon <dillon@apollo.backplane.com> 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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907201830.LAA06200>