[lkml]   [2002]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] 2.5.30 IDE 113
    Uz.ytkownik Jens Axboe napisa?:
    > On Tue, Aug 06 2002, Marcin Dalecki wrote:
    >>Uz.ytkownik Jens Axboe napisa?:
    >>>On Tue, Aug 06 2002, Marcin Dalecki wrote:
    >>>>Uz.ytkownik Jens Axboe napisa?:
    >>>>>On Tue, Aug 06 2002, Marcin Dalecki wrote:
    >>>>>>device not per channel! If q->request_fn would properly return the
    >>>>>>error count instead of void, we could even get rid ot the
    >>>>>>checking for rq->errors after finishment... But well that's
    >>>>>>entierly different story.
    >>>>>That's nonsense! What exactly would you return from a request_fn after
    >>>>>having queued, eg, 20 commands? Error count is per request, anything
    >>>>>else would be stupid.
    >>>>Returning the error count in the case q->request_fn is called for
    >>>>a self submitted request like for example REQ_SPECIAL would be handy and
    >>>>well defined. For the cumulative case it would of course make sense to
    >>>>return the cumulative error count. Tough not very meaningfull, it would
    >>>>indicate the occurrence of the error very fine.
    >>>It's much nicer to maintain a sane API that doesn't depend on stuff like
    >>>the above. Cumulative error count, come on, you can't possibly be
    >>Hey don't get me wrong - I *do not* suggest adding it becouse I don't
    >>think we are going to change the "eat as many as possible requests"
    >>instead of "eat one request" semantics of the q->reuqest_fn().
    > You look from the IDE perspective, I look from the interface
    > perspective. There's is no "eat one request" semantic of request_fn(),
    > in fact there's just the opposite. If you quit after having just
    > consumed one request, you must make sure to invoke request_fn _yourself_
    > later on -- or use the recent blk_start/stop_queue helpers.

    Yes of course I know that there is not "eat one request" semantic of
    request_fn(). However looking at the interface perspective (out of my
    small corner) I think the above is precisely what leads to ugly things
    (and I think you will agree that this is ugly) like calling
    do_ide_request() back out from ata_irq_handler() - shrug.

    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: 2005-03-22 13:27    [W:0.027 / U:204.040 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site