From owner-freebsd-hackers Tue Jul 20 11:19:54 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 678EB14CBB for ; Tue, 20 Jul 1999 11:19:52 -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 LAA19587; Tue, 20 Jul 1999 11:18:29 -0700 (PDT) env-from (jwm@CSUA.Berkeley.EDU) Message-Id: <199907201818.LAA19587@soda.CSUA.Berkeley.EDU> To: Matthew Dillon Cc: "David E. Cross" , freebsd-hackers@FreeBSD.ORG Subject: Re: USFS (User Space File System) In-reply-to: Message from Matthew Dillon of "Tue, 20 Jul 1999 10:14:44 PDT." <199907201714.KAA05685@apollo.backplane.com> Date: Tue, 20 Jul 1999 11:18:29 -0700 From: John Milford 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message