From owner-freebsd-current@FreeBSD.ORG  Tue Jan 24 01:09:13 2006
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
X-Original-To: current@freebsd.org
Delivered-To: freebsd-current@FreeBSD.ORG
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id C4F0E16A422
	for <current@freebsd.org>; Tue, 24 Jan 2006 01:09:13 +0000 (GMT)
	(envelope-from sbruno@miralink.com)
Received: from mazo.miralink.com (mail.miralink.com [70.103.185.26])
	by mx1.FreeBSD.org (Postfix) with ESMTP id E59C343D55
	for <current@freebsd.org>; Tue, 24 Jan 2006 01:09:12 +0000 (GMT)
	(envelope-from sbruno@miralink.com)
Received: from [10.1.1.47] (unknown [10.1.1.47])
	by mazo.miralink.com (Postfix) with ESMTP id DE25B36A30
	for <current@freebsd.org>; Wed, 18 Jan 2006 17:37:17 -0800 (PST)
From: Sean Bruno <sbruno@miralink.com>
To: current@freebsd.org
Content-Type: text/plain
Date: Wed, 18 Jan 2006 17:36:50 -0800
Message-Id: <1137634610.16906.22.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
Cc: 
Subject: 4.11 b_iodone callback question
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>, 
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jan 2006 01:09:13 -0000

I just inherited some older code that runs under 4.11 ... the core of
software is a device driver that writes data to two separate
disks(da1/da2).

It appears that the authors are using a call back function to handle
some interesting behavior related to the second disk being a circular
buffer.

So a couple of questions:

1.  Does the call back routine set in b_iodone(disk writes are handled
by VOP_STRATEGY) get invoked in a separate thread of execution, i.e. is
simultaneous with the main code path?

2.  Is it o.k. to have the callback routine invoke itself vi
b_iodone(more VOP_STRATEGY) without locking the buffers used for the
disk writes?

Sean Bruno