[lkml]   [2002]   [Mar]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] My AMD IDE driver, v2.7

    On Mon, 11 Mar 2002, Linus Torvalds wrote:
    > One solution may be to have the whole raw cmd thing as a loadable module,
    > and then I can make sure that it's not even available on the system so
    > that I have to do some work to find it, and somebody elses program won't
    > just know what to do.
    > But in that case is should be far removed from the IDE driver - it would
    > just be a module that inserts a raw request on the request queue, and NOT
    > inside some subsystem driver that I obviously want to have available all
    > the time.

    Let me put this proposal in more specific terms and see who hollers..

    First, the actual assumptions:
    - we should use the request queue, simply because that is the only thing
    that serializes access to all controllers - if we do not have any
    "sideband", there is no way to create the kind of confusion that we can
    create right now.

    - we want the approach to be generic, even if the details will end up
    being IDE/SCSI/xxx-specific.

    - I personally believe that we want to be able to do filtering
    independently of the controller driver, ie the filtering is not part of
    the driver infrastructure at all, but at a higher level (ie the same
    way network filtering has _nothing_ to do with any actual network
    drivers, regardless of what bus those drivers are on)

    Thus I would suggest against a filter inside the IDE driver, and instead
    suggest a loadable module that does

    - attach to one or more request queue(s). Notice that you should not have
    _one_ module that handles all request queues, because the filter module
    obviously has to be different for an ATA disk than for a SCSI disk, and
    in fact it might be different for an IBM ATA disk than for a Maxtor ATA
    disk, for example.

    - the module basically acts the way the SCSI generic driver does right
    now, except it acts on a higher level: instead of generating SCSI
    requests and feeding them directly to the driver with a scsi_do_req(),
    it would generate the command requests and feed it to the request

    In fact, don't think of it as the ATA thing at all: I'm more thinking
    along the lines of splitting up "sg.c" into the highlevel command
    generator (the biggest part) and a very _small_ part in the scsi
    request loop that understands about the generic command interface.

    If we can really do what sg.c does now, while at the _same_ time also have
    a "ide-generic" module that uses the exact same infrastructure, then I
    think I'm happy. Yes, the filtering is bus-specific (because the commands
    are bus-specific), but the general approach is common.

    Does anybody find any real downsides to this approach or basically trying
    to abstract sg.c "upwards" a bit?


    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:24    [W:0.025 / U:123.476 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site