From: Martin Dalecki <dalecki@evision-ventures.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: dalecki@evision.ag, Linus Torvalds <torvalds@transmeta.com>,
linux-kernel@vger.kernel.org
Subject: Re: Linux/Pro -- clusters
Date: Fri, 07 Dec 2001 11:56:23 +0100 [thread overview]
Message-ID: <3C10A057.BD8E1252@evision-ventures.com> (raw)
In-Reply-To: <E16CINX-0005MC-00@the-village.bc.nu>
Alan Cox wrote:
> > For example please grep for the MINOR() macro in the scsi layer...
> > Most of the places where it's used should be replaced by a simple
> > driver instance enumerator. I did this once already, so this is for
> > sure.
>
> it become block_device->instance or ->minor
Well if all the infromation those functions are needing would
be already in block_device in place, that it could become as easy
as just passing &block_device there.
However please note that replacing kdev_t in the scsi layer
with just passing the minor can be done already *now* without
any pain. The same applies to the excessive MINOR lookups in the
v4l code. I did this already some time ago (patch was here - about one
year ago)
> major/minors for old stuff still end up leaking into user space and
> mattering there. I'm not sure the best option for that
Thta's no problem. But they should be used as hash values no the
syscall implementation level and nowhere else.
--
- phone: +49 214 8656 283
- job: eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort:
ru_RU.KOI8-R
next prev parent reply other threads:[~2001-12-07 11:07 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-03 18:12 Linux/Pro -- clusters Donald Becker
2001-12-04 1:55 ` Davide Libenzi
2001-12-04 2:09 ` Donald Becker
2001-12-04 2:23 ` Davide Libenzi
2001-12-04 2:34 ` Alexander Viro
2001-12-04 9:10 ` Alan Cox
2001-12-04 9:30 ` Thomas Langås
2001-12-04 9:45 ` Alan Cox
2001-12-04 11:34 ` Thomas Langås
2001-12-05 21:57 ` Linus Torvalds
2001-12-05 23:05 ` Andre Hedrick
2001-12-06 4:31 ` Daniel Phillips
2001-12-05 23:49 ` Alan Cox
2001-12-05 23:48 ` Andre Hedrick
2001-12-06 16:58 ` Linus Torvalds
2001-12-06 18:02 ` Alan Cox
2001-12-06 18:07 ` Linus Torvalds
2001-12-06 18:12 ` Kai Henningsen
2001-12-06 20:46 ` Linus Torvalds
2001-12-06 22:40 ` Alan Cox
2001-12-06 18:33 ` Alan Cox
2001-12-06 18:55 ` Linus Torvalds
2001-12-06 19:19 ` Alan Cox
2001-12-06 20:37 ` Linus Torvalds
2001-12-06 22:35 ` Alan Cox
2001-12-06 22:34 ` Linus Torvalds
2001-12-06 22:58 ` Alexander Viro
2001-12-07 10:14 ` Martin Dalecki
2001-12-07 10:37 ` Alan Cox
2001-12-07 10:56 ` Martin Dalecki [this message]
2001-12-07 12:08 ` Alan Cox
2001-12-07 20:51 ` On re-working the major/minor system Erik Andersen
2001-12-07 21:21 ` H. Peter Anvin
2001-12-07 21:55 ` Erik Andersen
2001-12-07 22:04 ` H. Peter Anvin
2001-12-07 23:07 ` Erik Andersen
2001-12-07 23:12 ` H. Peter Anvin
2001-12-08 11:42 ` Alan Cox
2001-12-08 20:37 ` H. Peter Anvin
2001-12-09 12:06 ` Kai Henningsen
2001-12-09 21:57 ` H. Peter Anvin
2001-12-11 20:45 ` Kai Henningsen
2001-12-06 18:38 ` Linux/Pro -- clusters Doug Ledford
2001-12-04 14:37 ` Daniel Phillips
2001-12-04 15:19 ` Jeff Garzik
2001-12-04 17:16 ` Daniel Phillips
2001-12-04 17:20 ` Jeff Garzik
2001-12-04 18:04 ` Alan Cox
2001-12-04 18:16 ` Daniel Phillips
2001-12-04 20:20 ` Andrew Morton
2001-12-05 13:11 ` Deep look into VFS Martin Dalecki
2001-12-05 15:19 ` Alexander Viro
2001-12-05 15:30 ` Martin Dalecki
-- strict thread matches above, loose matches on Subject: below --
2001-12-08 1:50 Linux/Pro -- clusters Andries.Brouwer
2001-12-08 3:42 ` H. Peter Anvin
2001-12-08 17:26 Andries.Brouwer
2001-12-09 4:22 ` Linus Torvalds
2001-12-09 5:49 ` Alexander Viro
2001-12-09 8:59 Andries.Brouwer
2001-12-10 16:49 ` Alexander Viro
2001-12-10 17:09 ` Alan Cox
2001-12-11 8:39 ` Albert D. Cahalan
2001-12-10 19:36 Andries.Brouwer
2001-12-10 22:55 ` Alexander Viro
2001-12-10 19:51 Andries.Brouwer
2001-12-10 20:34 ` Alan Cox
2001-12-10 21:31 Andries.Brouwer
2001-12-10 21:44 ` Alan Cox
2001-12-10 22:48 Andries.Brouwer
2001-12-10 23:33 Andries.Brouwer
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=3C10A057.BD8E1252@evision-ventures.com \
--to=dalecki@evision-ventures.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dalecki@evision.ag \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/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