From owner-freebsd-scsi Sun Jun 21 11:13:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA12360 for freebsd-scsi-outgoing; Sun, 21 Jun 1998 11:13:34 -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 LAA12350 for ; Sun, 21 Jun 1998 11:13:29 -0700 (PDT) (envelope-from jonny@jonny.eng.br) Received: (from jonny@localhost) by roma.coe.ufrj.br (8.8.8/8.8.8) id PAA25621; Sun, 21 Jun 1998 15:13:11 -0300 (EST) (envelope-from jonny) From: Joao Carlos Mendes Luis Message-Id: <199806211813.PAA25621@roma.coe.ufrj.br> Subject: Re: Rolling CAM in, what is still needed? In-Reply-To: <199806210305.VAA20485@panzer.plutotech.com> from "Kenneth D. Merry" at "Jun 20, 98 09:05:37 pm" To: ken@plutotech.com (Kenneth D. Merry) Date: Sun, 21 Jun 1998 15:13:11 -0300 (EST) Cc: jonny@jonny.eng.br, ken@plutotech.com, mjacob@feral.com, julian@whistle.com, 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) // From ken@panzer.plutotech.com Sun Jun 21 00:06:01 1998 // From: "Kenneth D. Merry" // Message-Id: <199806210305.VAA20485@panzer.plutotech.com> // Subject: Re: Rolling CAM in, what is still needed? // In-Reply-To: <199806191742.OAA02683@roma.coe.ufrj.br> from Joao Carlos Mendes Luis at "Jun 19, 98 02:42:45 pm" // To: jonny@jonny.eng.br (Joao Carlos Mendes Luis) // Date: Sat, 20 Jun 1998 21:05:37 -0600 (MDT) // Cc: ken@plutotech.com, mjacob@feral.com, julian@whistle.com, // jonny@jonny.eng.br, ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG // X-Mailer: ELM [version 2.4ME+ PL28s (25)] // Joao Carlos Mendes Luis wrote... // > #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 ? // // My guess is that that is what it was supposed to do in theory, but // in practice, I don't think it does. I looked at the open routines in the // current cd, sd and st drivers, and none of them check to see if it was the // control device that was opened. So if no media is in the drive, the open // will fail. I had a problem recently, in which my CD drive booted locked, with or without a disk inside. With a disk inside I could just send the cdcontrol command to eject it, but without a disk inside I had to use scsi(8) commands, and they only worked with /dev/rcd0.ctl, failing at other devices because it could not open the device without a disk inside. I think that this is behaving as you expected. 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