From owner-freebsd-scsi Fri Mar 19 10:58: 0 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (Postfix) with ESMTP id 651E4150D4 for ; Fri, 19 Mar 1999 10:57:57 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.9.1/8.7.3) id LAA15363; Fri, 19 Mar 1999 11:48:35 -0700 (MST) Date: Fri, 19 Mar 1999 11:48:35 -0700 (MST) From: "Justin T. Gibbs" Message-Id: <199903191848.LAA15363@narnia.plutotech.com> To: "Matthew N. Dodd" Cc: scsi@FreeBSD.org Subject: Re: CAM entry point for SCSI-to-Ethernet device. X-Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (FreeBSD/4.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > My thought was to create 'scsi_se.[ch]' and let the driver live there (or > I can split up the network parts to live elsewhere) and in my csa.callback > routine examine the device name as well as the device type (T_PROCESSOR) > before attaching (so I know I have a valid SE device). > > Since I'd like the device to show up as 'seX' (woo!) this means that the > 'pt' driver will have to not attach (or attach in the way that the 'pass' > device does). > > Any ideas? In CAM, multiple drivers may attach to the same underlying device (e.g there is no special code to handle the 'pass' driver). So long as the pt device is not 'active' the se driver shouldn't care a bit about whether it has also attached to the cabeltron or not. Eventually, there will be locking primitives available for you to claim exclusive or shared access to the underlying device, but I haven't found the time to write them yet. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message