Date: Sat, 20 Mar 1999 18:00:45 -0700 From: "Justin T. Gibbs" <gibbs@plutotech.com> To: S ren Schmidt <sos@freebsd.dk> Cc: gibbs@plutotech.com (Justin T. Gibbs), current@FreeBSD.org Subject: Re: How to add a new bootdevice to the new boot code ??? Message-ID: <199903210109.SAA77557@pluto.plutotech.com> In-Reply-To: Your message of "Sat, 20 Mar 1999 10:58:56 %2B0100." <199903200958.KAA35050@freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
>> My main complaint so far about the new ATAPI stuff is that it duplicat= es >> or lacks (assuming it will be implemented) much of what CAM would have= >> given for almost free: >> = >> - Interrupt driven configuration > >That there allready, if we mean the same thing here. Right. Its duplicated functionality. >> - Peripheral driver to device routing > >Such as ? Such as the ability to have more than one driver share the same device, command generation counts and priority queuing to allow correct 'replay' of overlapped commands when an error occurs, etc. See: http://www.freebsd.org/~gibbs/cam.html for the start of a discussion of these features and why transaction routing was implemented this way. >> - debugging/tracing facilities >Well, there is a little of that allready, more to come. Right. Its duplicated functionality. >> - an extensible error recovery framework > >Well, here is room for improvement, I haven't put any real error >checking code in there by now, it will just fail and report that >for now. This is alpha level code remember. But how will you deal with errors especially when there are overlapped commands? CAM already deals with this in a very clean way. When an error= occurs, the controller driver freezes the queue of commands to the erring= device, notifies the peripheral driver of the error, and allows the drive= r to insert error recovery actions before any other commands are ever released to the device. This even allows you to toss back unexecuted but= queued commands at the controller level to be reinserted into the transpo= rt layer's command queue to ensure proper ordering. This all plays off of t= he priority features inherent in how transactions are queued. Command queuing was a major factor in why I wrote the CAM code. Solving these issues is not trivial. >> - an understanding of command queuing (also relevant for ATAPI) > >Hmm, well, yes, but I'm not sure that what ATA/ATAPI has to offer = >here is comaptible with the CAM framwork. I plan to support tagged >queueing on ATA disks though. CAM only knows that multiple commands may be outstanding at a time and that they must be marked with serial numbers for proper replay when an error occurs. The specifics of how multiple transactions are specified is something that can be completely isolated into the 'personality' module and as a protocol between the peripheral drivers and the controller drivers. >> - understanding of hot plug events > >This really isn't an issue on ATA/ATAPI devices in most cases, >but in the mobile world there is a need for this, but that is >already being worked on. We need alot of work in other places >in the kernel, before this can be really utilized though. So why invent a new notification and cleanup strategy when the CAM one has already been developed and tested in the SCSI world? >> - an aplication pass-thru interface > >Hmm, what for ?? cdrecord, a userland disk format utility, camcontrol functionality, etc. etc. >ATAPI commands could esily be passed through, but I'd like a >driver to be in charge here, and besides we allready have drivers >for most existing ATAPI HW. The pass-thru driver is in charge in the CAM world. Is this not sufficient? Sure, there needs to be locking primitives so that drivers competing for the same device do not step on each others toes, but this is already specified by CAM and should be only a day or so of effort to implement. >ATAPI has nothing to do in the da driver, well maybe for ZIP/LS120 >drives, but disks are ATA, and that needs translation. Why does it need translation? Why not simply issue ATA commands right through the CAM Transport layer. Perhaps you use a function table in you= r peripheral driver to build the right CAM Control Blocks to send for a particular device. Perhaps you have a completely different peripheral driver for ATA and SCSI devices. That is up to the implementor. My choi= ce would be to have one peripheral driver here, but CAM doesn't tie your han= ds one way or the other. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903210109.SAA77557>