[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.140 / U:0.572 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site