Date: Sun, 21 Mar 1999 16:06:34 -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: <199903212315.QAA93579@pluto.plutotech.com> In-Reply-To: Your message of "Sun, 21 Mar 1999 10:58:28 %2B0100." <199903210958.KAA37231@freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >> - 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 effec= t of overlapped commands on data integrity seems to be unspecified. Are th= ey 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 comman= d processing latency without mentioning the possibility of other optimizations, so perhaps this really is the case. Too bad they didn't ju= st define the two bits necessary (and left as spares in the tag specificatio= n register) to allow the same queuing feature set as SCSI. >> Command queuing was a major factor in why I wrote the CAM code. Solvi= ng >> 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 t= he 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 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?199903212315.QAA93579>