From owner-freebsd-scsi Fri Jun 19 10:51:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA01364 for freebsd-scsi-outgoing; Fri, 19 Jun 1998 10:51:17 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from roma.coe.ufrj.br (jonny@roma.coe.ufrj.br [146.164.53.65]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA01200 for ; Fri, 19 Jun 1998 10:50:17 -0700 (PDT) (envelope-from jonny@jonny.eng.br) Received: (from jonny@localhost) by roma.coe.ufrj.br (8.8.8/8.8.8) id OAA02683; Fri, 19 Jun 1998 14:42:45 -0300 (EST) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199806191742.OAA02683@roma.coe.ufrj.br> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806191730.LAA12458@panzer.plutotech.com> from "Kenneth D. Merry" at "Jun 19, 98 11:30:01 am" To: ken@plutotech.com (Kenneth D. Merry) Date: Fri, 19 Jun 1998 14:42:45 -0300 (EST) Cc: mjacob@feral.com, julian@whistle.com, ken@plutotech.com, jonny@jonny.eng.br, ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org #define quoting(Kenneth D. Merry) // - the problem is that with the old SCSI code, to send SCSI commands // directly to a device, you opened the device itself (/dev/rcd0a or // whatever) and did the SCIOCCOMMAND ioctl on that device. CAM does // things differently, primarily because users may want to send // commands to device, even though the device's open() routine may // fail. For instance, you can't open a CD device if there is no // media inserted. But the user may want to send an INQUIRY command // to the drive, whether or not there's a CD in the drive. So, to // solve this, you have two choices: (that I can think of offhand) // - have a special control minor number for each device, and // have the open call ignore failures in read capacity, test // unit ready, etc. // - have a separate passthrough driver that doesn't have to // have any commands succeed to attach or open. Isn't this what /dev/xxx.ctl does ? // For CAM, we chose the latter. Anyway, I've gotta go, so I'll // just say that in order to have devices respond to the // SCIOCCOMMAND ioctl in the same way, we'd have to wire code to // handle that ioctl into each device driver's ioctl routine. // (probably in cam_periph_ioctl()) // // I'd rather not kludge any of this up, though, unless someone can // make a compelling case that it needs to be done. Maybe it's not a big problem, considering the ports collection. :) For me, the most important is to have the rules clearly defined. Being said that, both options are good enough. Jonny -- Joao Carlos Mendes Luis M.Sc. Student jonny@jonny.eng.br Universidade Federal do Rio de Janeiro To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message