Date: Sun, 19 Sep 1999 12:11:32 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@netplex.com.au> Cc: Matthew Jacob <mjacob@feral.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, dg@root.com, Greg Lehey <grog@lemis.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: User block device access (was: cvs commit: src/sys/miscfs/specfs spec_vnops.c src/sys/sys vnode.h src/sys/kern vfs_subr.c) Message-ID: <199909191911.MAA73893@apollo.backplane.com> References: <19990919183556.802C81CA7@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
:I personally like the idea of doing buffered IO via the VM system. After
:all, the device has a backing vnode, and as you pointed out, using the VM
:system is only slightly slower than using the bdev and the bio cache
:directly. It has a number of advantages, namely simplifying the caching
:aspects of everything a fair bit since there are no longer coherency
:measures between bio and vm to maintain as the bio layer ends up with no
:caching at all. Opening and accessing a block (buffered) device would
:still look exactly the same to the user, but would be going via a pager
:rather than bread/bwrite and the hassles that causes. struct buf then
:becomes just a plain IO request for the device interface. Of course, this
:is easier said than done so I'll shut up now. :-)
:
:Cheers,
:-Peter
The patch below will implement mmap() on block devices.
Assuming I cleanup the below patch to also test against securelevel
(to disallow shared R+W mmap's of block devices when securelevel has
been bumped), does anyone other then Poul have any objections?
I think write-through can be implemented fairly easily too. We simply
push the buffers out synchronously as they are dirtied and return an
error from write(). I would even be willing to make it the default.
People who don't care can use mmap() (which is inherently asynchronous
in regards to writes). People who do care can use write() and get
instant gratification.
And, of course, when you mmap() a buffered block device you avoid the
extra copy overhead, which would make the buffered block device just
about as fast for cache-miss situations as a raw device.
-Matt
Matthew Dillon
<dillon@backplane.com>
Index: vm/vm_mmap.c
===================================================================
RCS file: /home/ncvs/src/sys/vm/vm_mmap.c,v
retrieving revision 1.102
diff -u -r1.102 vm_mmap.c
--- vm_mmap.c 1999/08/28 00:52:39 1.102
+++ vm_mmap.c 1999/09/19 18:56:12
@@ -249,7 +249,7 @@
if (fp->f_type != DTYPE_VNODE)
return (EINVAL);
vp = (struct vnode *) fp->f_data;
- if (vp->v_type != VREG && vp->v_type != VCHR)
+ if (vp->v_type != VREG && vp->v_type != VCHR && vp->v_type != VBLK)
return (EINVAL);
/*
* XXX hack to handle use of /dev/zero to map anon memory (ala
Index: sys/vnode.h
===================================================================
RCS file: /home/ncvs/src/sys/sys/vnode.h,v
retrieving revision 1.100
diff -u -r1.100 vnode.h
--- vnode.h 1999/09/17 06:10:27 1.100
+++ vnode.h 1999/09/19 18:30:37
@@ -463,7 +462,7 @@
static __inline int
vn_canvmio(struct vnode *vp)
{
- if (vp && (vp->v_type == VREG || (vmiodirenable && vp->v_type == VDIR)))
+ if (vp && (vp->v_type == VREG || vp->v_type == VBLK || (vmiodirenable && vp->v_type == VDIR)))
return(TRUE);
return(FALSE);
}
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909191911.MAA73893>