>> >> - 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...
I just read the ATA5 draft (couldn't find the last ATA4 draft at the wdc website). I don't see any issues here other than the fact that the effect of overlapped commands on data integrity seems to be unspecified. Are they always handled in FIFO order? Can reads be seek optimized? What happens in the case of a queued write after a queued read to the same location? My hope is that, since the spec does not allow you to specify the sorting restrictions on a per request basis as you can in SCSI, FIFO ordering is implied. They even mention that the feature is intended to overlap command processing latency without mentioning the possibility of other optimizations, so perhaps this really is the case. Too bad they didn't just define the two bits necessary (and left as spares in the tag specification register) to allow the same queuing feature set as SCSI. >> 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 ?? Yes. >> >> - 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 :) ), Almost all newer SCSI cd burners use MMC now and cdrecord supports MMC devices. Why write another utility if there is already one that speaks the necessary language that our users are familiar with? >OK, I'm done discussing this (se my other mail), I'd rater spend >my (very limitted) time productively. Fair enough. -- Justin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
