:
:Matthew Dillon <dil...@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
<dil...@backplane.com>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
