[lkml]   [2007]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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?
    - check and reject if something wrong
    - mimimal check and warn/ignore, if it doesn't hurt command execution


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-06-13 04:59    [W:0.031 / U:6.104 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site