On Mon, 4 Sep 2000, Mark Hahn wrote:
> > You and several others know that I stink at describing a complex point
> > regardless that I understand it completely. I am just glad that you hung
> > in there long enough for me to get the point across.
>
> Andre, as far as I can tell, this "complex point" is just the kind of
> queueing that SCSI has done all along. sure, if you want to juggle
> multiple outstanding commands, you need a structure to track them.
>
> what continues to mystify me is why you believe that it's appropriate
> for the driver to prevent any op it doesn't understand. yes, it needs
Go read section 9 pages 229->295 of d1410r0a.pdf
ftp://fission.dt.wdc.com/pub/standards/x3t13/project/d1410r0a.pdf
This is the state diagram and the rules for talking to drives.
If you do not match the command/sub-command with the protocol then you
screw things up. On a good day you lock a system or crash. Bad days the
price could be unlimited.
If the vendor uses a standard protocol, then we need to know about it.
Regardless, the IOCTL interface will change to adopt a possible user
select protocol, if possible. Then everyone will have to read these pages
to understand what I wanted to make simple. Since I can not make it
simple, because people do not understand, lets go for a painful interface
that will make root happy.
Since the current level of taskfile is only 28-bit that means it will be
easier than 48-bit. The execution of the HOB (high order bit) for the
double pump of the LBA in all the various changes will drive me crazy
making it simple to use. So you will do me a huge favor to allow me to
execute the change with a RAW array of bytes to pass in the IOCTL arg
parameter.
Since the loading rules vary based on the command/op code and we are still
writing them, it will be fun.
> to track the tags of queued commands, including those via ide_ioctl.
> but ensuring tag sanity is very different from filtering.
It is more than tag tracking. If you read the 404 page PDF you will
understand that there is a reason beyond what is easily explainable.
Cheers,
Andre Hedrick
The Linux ATA/IDE guy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:18 EST