From owner-freebsd-current  Mon Mar 20 13:30: 2 2000
Delivered-To: freebsd-current@freebsd.org
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by hub.freebsd.org (Postfix) with ESMTP
	id 7322937BA65; Mon, 20 Mar 2000 13:29:53 -0800 (PST)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.9.3/8.9.1) id NAA71883;
	Mon, 20 Mar 2000 13:29:51 -0800 (PST)
	(envelope-from dillon)
Date: Mon, 20 Mar 2000 13:29:51 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200003202129.NAA71883@apollo.backplane.com>
To: Julian Elischer <julian@elischer.org>
Cc: Poul-Henning Kamp <phk@FreeBSD.ORG>, current@FreeBSD.ORG
Subject: Re: B_WRITE cleanup patch, please test!
References: <20502.952948995@critter.freebsd.dk> <38CCEF68.41C67EA6@elischer.org>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    I think the biggest win in regards to being able to arbitrarily stack
    devices is to NOT attempt to forward struct buf's between devices when
    non-trivial manipulation is required, and instead to make struct buf's
    cheap enough that a device can simply allocate a new one and copy the
    appropriate fields.  Here I am talking about situations where devices
    need callbacks (making forwarding impossible), need to split or combine
    requests, or do other non-trivial things.

    In particular I really hate all the various b_*blkno fields.  b_lblkno,
    b_blkno, and b_pblkno.  It is precisely due to the existance of these
    hacks that arbitrary device stacking is difficult.

    The key to making a struct buf cheap is to provide an I/O path that
    does not require the b_data KVA mapping.  Once we provide this path,
    I think everything else will fall into place quite neatly.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message