From owner-freebsd-current Sun Mar 21 15:17: 3 1999 Delivered-To: freebsd-current@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id D5C5B14BE2 for ; Sun, 21 Mar 1999 15:16:57 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id QAA93579; Sun, 21 Mar 1999 16:15:35 -0700 (MST) (envelope-from gibbs@plutotech.com) Message-Id: <199903212315.QAA93579@pluto.plutotech.com> X-Mailer: exmh version 2.0.2 2/24/98 To: S ren Schmidt Cc: gibbs@plutotech.com (Justin T. Gibbs), current@FreeBSD.ORG Subject: Re: How to add a new bootdevice to the new boot code ??? In-reply-to: Your message of "Sun, 21 Mar 1999 10:58:28 +0100." <199903210958.KAA37231@freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sun, 21 Mar 1999 16:06:34 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >> >> - 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