lkml.org 
[lkml]   [2007]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: libata passthru: support PIO multi commands
Alan Cox wrote:
>>ata_scsi_pass_thru() is not executed at ioctl submission time (block
>>queue submission time), but rather immediately before it is issued to
>>the drive. At that point you know the bus is idle, all other commands
>>have finished executing, and dev->multi_count is fresh not stale. The
>>code path goes from ata_scsi_pass_thru() to ata_qc_issue() without
>>releasing the spinlock, even.
>
>
> Think up to user space
>
> Poorusersapp set multicount to 4
>
> Evilproprietarytuningdaemon set multicount to 8
>
> Poorusersapp issue I/O
>
> at which point an error is indeed best.
>
>
>>But the last point is true -- we should error rather than just warn
>>there, AFAICS.
>
>
> Definitely. We've been asked "please do something stupid" and not even in
> a case where the requester may know better.
>

It looks like the ATA passthru commands contain more information than
what libata needs to execute a command.

e.g. protocol number:
libata could possibly infer the protocol from the command opcode.

e.g. multi_count:
libata caches dev->multi_count. Passing multi_count along with
each passthru command looks useless for libata.

e.g. t_dir:
libata could possible infer the direction from the command opcode
or from the protocol number (e.g. 4: PIO_IN / 5: PIO_OUT).

Due to the redundant info, there is possiblely inconsistency between
the parameters. e.g. t_dir vs protocol. e.g. command vs protocol.

It seems the "redundant" parameters are designed to allow stateless SATL
implementation: The application/passthru command tells the stateless SATL
implementation the protocol and the multi_count, etc. Then SATL just
follows the instruction blindly, even if asked to do something stupid.

Currently libata
- uses the passthru protocol number blindly
(even if the application issues a DMA command with wrong PIO protocol.)
- checks and warns about multi_count
- ignores t_dir, byte_block and so on.

Maybe we need a strategy to deal with incorrect passed-thru commands?
say,
- check and reject if something wrong
- mimimal check and warn/ignore, if it doesn't hurt command execution

--
albert

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-06-13 04:59    [W:0.077 / U:0.024 seconds]
©2003-2014 Jasper Spaans. Advertise on this site