lkml.org 
[lkml]   [2002]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] 2.5.15 IDE 61
    Alan Cox wrote:
    > If the queue abstraction is right then the block layer should do all the
    > synchronization work that is required.

    I think you're wrong Alan. Take a good IDE chipset as an example: both
    channels can be active at the same time, but you still can't talk to one
    drive while the other drive on the same channel is DMAing.

    I'm not a block layer expert, but it appears to me that the block layer
    only synchronises requests by use of the spinlock. If I'm right, then
    the block layer has no way of knowing that hda is DMAing when a request
    is initiated for hdb. This was the whole reason (as I see it) that
    hwgroup->busy existed: to prevent attempts to use the same IDE cable for
    two things at the same time.

    It doesn't matter how you perform the queue abstraction in this case:
    the fact that the device+channel+cable is busy in an asynchronous manner
    makes it impossible for the block layer to deal with this. [[Or am I
    way off base?!]]

    The right way is the way it is being done at present surely: if the busy
    flag on the hwgroup is set, then ide_do_request() just returns. (NB:
    When I say "right way", I don't mean to imply that the code is elegant,
    desirable, or even bug-free, just that it correctly handles this busy
    state.)

    >It may cost a few cycles on the odd
    > case you can do overlapped command setup but that versus a nasty locking
    > mess its got to be better to lose those few cycles.

    Well, Jens and others are busy implementing TCQ where things are just so
    much easier to fsck up :-))

    > I don't even Martin here, the ide locking is currently utterly vile

    Agreed, but surely with some concerted effort we can truly fix the IDE
    code. Can't be beyond us all can it?

    Neil
    -
    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: 2005-03-22 13:26    [W:4.154 / U:0.212 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site