Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Oct 1999 18:40:06 +0800
From:      Peter Wemm <peter@netplex.com.au>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Poul-Henning Kamp <phk@critter.freebsd.dk>, "Daniel C. Sobral" <dcs@newsguy.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/vm vm_swap.c 
Message-ID:  <19991011104006.AE4631CC8@overcee.netplex.com.au>
In-Reply-To: Your message of "Mon, 11 Oct 1999 00:09:58 MST." <199910110709.AAA20043@apollo.backplane.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote:
> :> 
> :>     We're not removing the device interface.  It provides a reasonable
> :>     abstraction and a nice demark between swap_pager.c and vm_swap.c,
> :>     as well as potential flexibility that could be useful in the future
> :>     Removing it will not save time or much in the way of code space.
> :
> :The swap *device* is non-functional and doesn't *do* anything except
> :provide a subroutine call in a very roundabout way.  I think it would be
> :far better to avoid an indirection via the VOP_* system for no useful gain
> :and do something like the aooended patch (which works perfectly here BTW,
> :even under heavy swap load on multiple disks).  Further (micro)
> :optimizations are possible, for example pbgetvp() is used to get a p-buffer
> :that's associated with swapdev_vp and the device.  The device isn't used
> :and presently vn_todev(vp) ends up returning NODEV.  swapdev_vp is kinda
> :orphaned with this change but still works ok. p-buffers are created being
> 
>     Gentlemen.  You might as well stop.  I've said it before and I
>     will say it again:  Nobody is screwing around with the swap 
>     subsytem.  I spent a lot of time on that subsytem, including weeks
>     of testing.  I am essentially the maintainer for it, and I am not 
>     going to allow people to mess with it based on a few hacks.  Just
>     because the swap subsystem uses a small subset of the device 
>     interface doesn't mean you can hack it up to remove it.  You are not
>     'fixing' anything by doing so.  You aren't making the system more reliabl
    e,
>     you aren't making the system run better.  You are just making my job
>     harder by forcing me to retest everything.  So it isn't going to happen.

Oh come on now!  Your "testing" didn't even find that reading /dev/drum was
an instant guaranteed system panic.  This patch does not change a thing
except remove dead code that is almost certain to break shortly.

Cheers,
-Peter



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?19991011104006.AE4631CC8>