Date: Fri, 19 Jun 1998 11:30:01 -0600 (MDT) From: "Kenneth D. Merry" <ken@plutotech.com> To: mjacob@feral.com (Matthew Jacob) Cc: julian@whistle.com, ken@plutotech.com, jonny@jonny.eng.br, ckempf@enigami.com, freebsd-scsi@FreeBSD.ORG Subject: Re: Rolling CAM in, what is still needed? Message-ID: <199806191730.LAA12458@panzer.plutotech.com> In-Reply-To: <358A909B.1DF72290@feral.com> from Matthew Jacob at "Jun 19, 98 09:23:55 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Jacob wrote... > Julian Elischer wrote: > > > > Surely the old interface is pretty generic.. > > > > (userland scsi that is) > > Yes, but how many of these are there that Ken hasn't done yet? Right, that's what I'm interested in. I talked to Julian this morning (in person, actually!) and that's the question I had. So I'll say it so everyone can see: - How many more programs use this (scsireq) interface? - Are people going to yell and scream loudly if it goes away when CAM is integrated into the tree?? I have already ported the largest application I know of that used the old scsireq interface. (I did it last fall, it's a big part of Pluto's products.) As far as generally available applications, I ported xmcd, Mike Smith ported cdrecord and Russell Cattelan has ported tosha. That leaves SANE and cdd. What other applications are out there, either publically available or in use privately? > If it's really a consensus on everyone's part to have the OLD > interfaces around, Ken, I'll help integrate that. Yeah, if there is enough need for it, I think we can do something, at least for one release or so. There are several issues here: - the old SCIOCCOMMAND ioctl can be emulated in the current passthrough driver, I did it at one time last year. - 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. 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. [ p.s. I won't be able to answer email again until tomorrow night. ] Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806191730.LAA12458>