Date: Sun, 21 Mar 1999 10:58:28 +0100 (CET) From: Søren Schmidt <sos@freebsd.dk> To: gibbs@plutotech.com (Justin T. Gibbs) Cc: gibbs@plutotech.com, current@FreeBSD.ORG Subject: Re: How to add a new bootdevice to the new boot code ??? Message-ID: <199903210958.KAA37231@freebsd.dk> In-Reply-To: <199903210109.SAA77557@pluto.plutotech.com> from "Justin T. Gibbs" at "Mar 20, 1999 6: 0:45 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
It seems Justin T. Gibbs wrote: > >> My main complaint so far about the new ATAPI stuff is that it duplicates > >> 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. Nope, not exactly.. > >> - 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 That will probably need changes to work with ATA4's tagged queing at least... > >> - 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 driver > 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 transport > layer's command queue to ensure proper ordering. This all plays off of the > 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. Agreed, but have you looked at how ATA4 handles queing ?? > >> - an aplication pass-thru interface > > > >Hmm, what for ?? > > cdrecord, a userland disk format utility, camcontrol functionality, > etc. etc. He he, ATAPI dont need cdrecord as all ATAPI burners use the same command set (MMC), where your average SCSI burner has its own propietary command set (well, the ATA/ATAPI guys did get one thing right :) ), There might be an idea for formatting utils for LS120/ZIP drives, ATA harddisks should not be formatted, in fact the ignore the command more or less. OK, I'm done discussing this (se my other mail), I'd rater spend my (very limitted) time productively. -Søren 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?199903210958.KAA37231>