From owner-freebsd-current Sun Jun 18 20:34:53 2000 Delivered-To: freebsd-current@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id 0FC8B37BB28 for ; Sun, 18 Jun 2000 20:34:51 -0700 (PDT) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.10.1/8.10.1) id e5J3Ynt02181; Sun, 18 Jun 2000 23:34:49 -0400 (EDT) Date: Sun, 18 Jun 2000 23:34:49 -0400 (EDT) From: Luoqi Chen Message-Id: <200006190334.e5J3Ynt02181@lor.watermarkgroup.com> To: phk@critter.freebsd.dk Subject: Re: HEADSUP: bioops patch. Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >> Background: > > >> Ideally struct buf should have had a real OO like operations vector > >> like vnodes have it, and struct bioops is the first step towards that. > >> > >struct buf will eventually become merely an iocmd structure, so why do > >we want to complicate things here? > > No, struct buf will remain the cache-handle. the iocmd is called > struct bio. > Even if struct buf stays around, its cache-handle role will be diminished, probably just a translation layer to vm object based caching. > >We already have an OO method for bwrite: VOP_BWRITE(), the problem > >is most of the code are still calling bwrite() directly. Will it > >solve your problem if we change every bwrite() into a VOP_BWRITE()? > > Well, I'm not sure it is correct to go the detour around Vnodes, > if we do, we need to add VOP_BAWRITE, VOP_BDWRITE and all those > other operations as well. > Don't you need bp->b_ops->bawrite(), bp->b_ops->bdwrite() as well? I feel it's better to go through the vnode, because for all the bufs belong to the same vnode, these b_ops are most likely to be the same. And for a stackable filesystem, you may easily implement a passthru call with vnode, how would you deal with it using struct buf? > But what vnode would you use for a buffer associated with a freeblock > bitmap ? > Each buffer belongs to a vnode, a buffer associated with a freeblock bitmap belongs to the device vnode, and that's the vnode we could use. > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message