From: Linus Torvalds <torvalds@transmeta.com>
To: Jeff Garzik <jgarzik@mandrakesoft.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Alan Cox <alan@redhat.com>
Subject: Re: [patch] My AMD IDE driver, v2.7
Date: Mon, 11 Mar 2002 19:58:32 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.33.0203111944090.18649-100000@penguin.transmeta.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0203111916000.18604-100000@penguin.transmeta.com>
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
queue.
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?
Linus
next prev parent reply other threads:[~2002-03-12 4:00 UTC|newest]
Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-11 15:13 [patch] My AMD IDE driver, v2.7 Vojtech Pavlik
2002-03-11 16:36 ` Martin Dalecki
2002-03-11 20:49 ` Rik van Riel
2002-03-11 22:45 ` Alan Cox
2002-03-11 22:39 ` Linus Torvalds
2002-03-11 22:45 ` Vojtech Pavlik
2002-03-11 22:53 ` Linus Torvalds
2002-03-12 0:14 ` Bill Davidsen
2002-03-12 0:34 ` Jeff Garzik
2002-03-12 0:58 ` Erik Andersen
2002-03-12 1:33 ` Jeff Garzik
2002-03-12 1:41 ` Linus Torvalds
2002-03-12 1:50 ` Jeff Garzik
2002-03-11 18:50 ` gmack
2002-03-12 2:19 ` Linus Torvalds
2002-03-12 2:34 ` Jeff Garzik
2002-03-12 11:21 ` Martin Dalecki
2002-03-12 2:54 ` J. Dow
2002-03-12 6:32 ` Vojtech Pavlik
2002-03-14 15:12 ` Pavel Machek
2002-03-13 18:42 ` Horst von Brand
2002-03-13 19:11 ` Andre Hedrick
2002-03-12 6:25 ` Vojtech Pavlik
2002-03-12 7:13 ` Erik Andersen
2002-03-12 16:40 ` Bill Davidsen
2002-03-12 0:51 ` Linus Torvalds
2002-03-12 1:41 ` Jeff Garzik
2002-03-12 1:44 ` Linus Torvalds
2002-03-12 2:22 ` Jeff Garzik
2002-03-12 2:33 ` Linus Torvalds
2002-03-12 2:37 ` Jeff Garzik
2002-03-12 3:34 ` Olivier Galibert
2002-03-12 4:13 ` Jeff Garzik
2002-03-14 14:13 ` Pavel Machek
2002-03-15 11:05 ` Jeff Garzik
2002-03-18 19:20 ` Pavel Machek
2002-03-19 9:29 ` Vojtech Pavlik
2002-03-19 21:21 ` Pavel Machek
2002-03-19 21:56 ` Vojtech Pavlik
2002-03-20 8:00 ` Daniela Engert
2002-03-20 18:11 ` Bill Davidsen
2002-03-20 18:46 ` Daniela Engert
2002-03-20 22:15 ` Pavel Machek
2002-03-20 23:09 ` Daniel Kobras
2002-03-19 22:33 ` Andre Hedrick
2002-03-20 0:25 ` Alan Cox
2002-03-15 14:45 ` Alan Cox
2002-03-12 11:23 ` Martin Dalecki
2002-03-12 2:50 ` J. Dow
2002-03-12 3:10 ` Jeff Garzik
2002-03-12 3:28 ` Linus Torvalds
2002-03-12 3:46 ` Jeff Garzik
2002-03-12 6:10 ` J. Dow
2002-03-12 3:58 ` Linus Torvalds [this message]
2002-03-12 4:26 ` Jeff Garzik
2002-03-12 4:40 ` Linus Torvalds
2002-03-12 6:26 ` J. Dow
2002-03-12 11:44 ` Martin Dalecki
2002-03-12 4:31 ` Linus Torvalds
2002-03-12 5:05 ` Jeff Garzik
2002-03-12 5:20 ` Linus Torvalds
2002-03-12 11:39 ` Martin Dalecki
2002-03-12 4:49 ` Erik Andersen
2002-03-12 5:08 ` Linus Torvalds
2002-03-12 11:36 ` Martin Dalecki
2002-03-12 6:05 ` J. Dow
2002-03-12 4:41 ` Erik Andersen
2002-03-12 4:48 ` Jeff Garzik
2002-03-12 6:30 ` J. Dow
2002-03-12 6:29 ` J. Dow
2002-03-12 16:36 ` Bill Davidsen
2002-03-12 2:57 ` Alan Cox
2002-03-12 2:49 ` Jeff Garzik
2002-03-12 11:17 ` Alan Cox
2002-03-13 8:14 ` ide filters / 'ide dump' / 'bio dump' bert hubert
2002-03-13 10:11 ` Jeff Garzik
2002-03-13 12:05 ` Malcolm Beattie
2002-03-13 17:17 ` Linus Torvalds
2002-03-12 11:10 ` [patch] My AMD IDE driver, v2.7 Martin Dalecki
2002-03-12 0:33 ` benh
2002-03-12 20:21 ` Gunther Mayer
2002-03-12 16:33 ` Bill Davidsen
2002-03-12 11:00 ` Martin Dalecki
2002-03-12 15:59 ` Vojtech Pavlik
2002-03-12 16:11 ` Martin Dalecki
2002-03-12 16:21 ` Vojtech Pavlik
2002-03-12 16:26 ` Martin Dalecki
2002-03-12 16:33 ` Vojtech Pavlik
2002-03-12 16:41 ` Martin Dalecki
2002-03-13 0:01 ` Russell King
2002-03-12 16:43 ` Martin Dalecki
2002-03-12 16:50 ` Vojtech Pavlik
2002-03-12 16:58 ` Martin Dalecki
2002-03-14 14:02 ` Pavel Machek
2002-03-15 11:13 ` Vojtech Pavlik
2002-03-18 19:21 ` Pavel Machek
2002-03-13 19:43 ` Bill Davidsen
2002-03-12 16:44 ` Sebastian Droege
2002-03-12 16:17 ` Martin Dalecki
2002-03-12 16:27 ` Vojtech Pavlik
2002-03-12 16:32 ` Martin Dalecki
2002-03-12 20:00 ` [patch] PIIX driver rewrite Vojtech Pavlik
2002-03-12 20:35 ` Sebastian Droege
2002-03-12 20:34 ` Vojtech Pavlik
2002-03-12 21:07 ` Sebastian Droege
2002-03-12 21:19 ` Vojtech Pavlik
2002-03-11 23:01 ` [patch] My AMD IDE driver, v2.7 Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.33.0203111944090.18649-100000@penguin.transmeta.com \
--to=torvalds@transmeta.com \
--cc=alan@redhat.com \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).