Skip site navigation (1)Skip section navigation (2)
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>