From: Martin Dalecki <dalecki@evision-ventures.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linus Torvalds <torvalds@transmeta.com>, linux-kernel@vger.kernel.org
Subject: Re: Linux/Pro -- clusters
Date: Fri, 07 Dec 2001 11:14:00 +0100 [thread overview]
Message-ID: <3C109668.E5818E11@evision-ventures.com> (raw)
In-Reply-To: <E16C3Kn-0002XC-00@the-village.bc.nu>
> > It's called "struct block_device" and "struct genhd". The pointers will
> > have as many bits as pointers have on the architecture. Low-level drivers
> > will not even see anything else eventually, there will be no "numbers".
>
> For those of us who want to run a standards based operating system can
> you do the 32bit dev_t. Otherwise some slightly fundamental things don't
> work. You know boring stuff like ls, find, df, and other standard unix
> commands. Those export a dev_t cookie.
I don't think this is what Linus was talking about. The current problem
is that at many places the drivers (not the generic layer) know too
much about stuff, which should be handled entierly on the genric device
type layer. And changing this is actually a *prerequsite* to change
the type of dev_t.
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.
> If you don't want to be able to run stuff like ls, just let me know and
> I'll start another kernel tree 8)
next prev parent reply other threads:[~2001-12-07 10:24 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 [this message]
2001-12-07 10:37 ` Alan Cox
2001-12-07 10:56 ` Martin Dalecki
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=3C109668.E5818E11@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