From: Martin Dalecki <dalecki@evision-ventures.com>
To: Andries.Brouwer@cwi.nl
Cc: viro@math.psu.edu, linux-kernel@vger.kernel.org, torvalds@transmeta.com
Subject: Re: [PATCH] struct char_device
Date: Tue, 22 May 2001 23:17:18 +0200 [thread overview]
Message-ID: <3B0AD75E.92D44A49@evision-ventures.com> (raw)
In-Reply-To: <UTC200105222054.WAA79836.aeb@vlet.cwi.nl>
Andries.Brouwer@cwi.nl wrote:
>
> > They are entirely different. Too different sets of operations.
>
> Maybe you didnt understand what I meant.
> both bdev and cdev take care of the correspondence
> device number <---> struct with operations.
>
> The operations are different, but all bdev/cdev code is identical.
>
> So the choice is between two uglies:
> (i) have some not entirely trivial amount of code twice in the kernel
> (ii) have a union at the point where the struct operations
> is assigned.
>
> I preferred the union.
>
> >> And a second remark: don't forget that presently the point where
> >> bdev is introduced is not quite right. We must only introduce it
> >> when we really have a device, not when there only is a device
> >> number (like on a mknod call).
>
> > That's simply wrong. kdev_t is used for unopened objects quite often.
>
> Yes, but that was my design mistake in 1995.
I fully agree with you. Most of the places where there kernel is passing
kdev_t
would be entierly satisfied with only the knowlendge of the minor number
used to
distinguish between different device ranges, which is BTW an abuse by
itself as well
since minors where for encounters of instances of similiar devices in
linux...
The places where this is the case are namely:
1. literally: all character devices.
2. The whole scsi stuff.
3. most of the ide stuff.
4. md/lvm and similiar culprits.
I did "discover" this by splitting the i_dev field from stuct inode
into explicit i_minor and i_major fields and then actually "fixing" my
particular kernel configuration until it worked again. This was
*very* insigtfull, since it discovered all the places where kdev_t get's
used, where it shouldn't be of any need anylonger anyway.
The remaining places where kdev_t comes into sight are mostly
the places where the kernel is mounting the initial root
device.
In case you would like to have a look at the resulting bit huge
patch I can send it to you...
> I think you'll find if you continue on this way,
> as I found and already wrote in kdev_t.h
> that it is bad to carry pointers around for unopened and unknown devices.
>
> So, I think that the setup must be changed a tiny little bit
> and distinguish meaningless numbers from devices.
>
> Andries
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
- 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-05-22 21:18 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-22 20:54 [PATCH] struct char_device Andries.Brouwer
2001-05-22 21:17 ` Martin Dalecki [this message]
2001-05-22 22:37 ` Linus Torvalds
2001-05-22 23:51 ` Alexander Viro
2001-05-23 0:06 ` Jeff Garzik
2001-05-23 0:14 ` Jens Axboe
2001-05-23 2:37 ` Linus Torvalds
2001-05-23 3:04 ` Jeff Garzik
2001-05-23 3:21 ` Jeff Garzik
2001-05-23 9:05 ` Alan Cox
2001-05-23 2:35 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2001-05-23 20:01 Andries.Brouwer
2001-05-23 18:28 Andries.Brouwer
2001-05-23 18:42 ` Alexander Viro
2001-05-23 15:24 Wayne.Brown
2001-05-23 13:34 Andries.Brouwer
2001-05-23 17:54 ` Alexander Viro
2001-05-24 10:35 ` Stephen C. Tweedie
2001-05-23 12:29 Andries.Brouwer
2001-05-23 12:30 ` Alan Cox
2001-05-23 13:26 ` Helge Hafting
2001-05-23 11:57 Andries.Brouwer
2001-05-23 12:13 ` Alan Cox
2001-05-23 6:47 Andries.Brouwer
2001-05-23 0:28 Andries.Brouwer
2001-05-23 0:38 ` Alexander Viro
2001-05-23 0:22 Andries.Brouwer
2001-05-23 0:29 ` Martin Dalecki
2001-05-23 0:20 Andries.Brouwer
2001-05-23 2:43 ` Linus Torvalds
2001-05-23 0:01 Andries.Brouwer
2001-05-22 23:33 Andries.Brouwer
2001-05-23 0:03 ` Alexander Viro
2001-05-22 22:17 Andries.Brouwer
2001-05-22 22:34 ` Martin Dalecki
2001-05-22 22:47 ` Martin Dalecki
2001-05-23 0:02 ` Jeff Garzik
2001-05-23 0:14 ` Jens Axboe
2001-05-23 2:40 ` Linus Torvalds
2001-05-23 12:35 ` Martin Dalecki
2001-05-22 21:35 Andries.Brouwer
2001-05-22 22:00 ` Martin Dalecki
2001-05-22 19:52 Andries.Brouwer
2001-05-22 20:10 ` Alexander Viro
[not found] <Pine.GSO.4.21.0105221007460.15685-100000@weyl.math.psu.edu >
2001-05-22 15:26 ` Anton Altaparmakov
2001-05-22 16:08 ` Oliver Xymoron
2001-05-22 16:12 ` Alexander Viro
2001-05-22 17:30 ` Oliver Xymoron
2001-05-22 17:41 ` Alexander Viro
2001-05-22 19:22 ` Guest section DW
2001-05-22 19:25 ` Alexander Viro
2001-05-22 19:38 ` Oliver Xymoron
[not found] <Pine.LNX.4.10.10105221050080.8984-100000@coffee.psychology.mcmaster.ca>
2001-05-22 14:59 ` Tommy Hallgren
2001-05-22 14:40 Tommy Hallgren
2001-05-22 14:18 Alexander Viro
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=3B0AD75E.92D44A49@evision-ventures.com \
--to=dalecki@evision-ventures.com \
--cc=Andries.Brouwer@cwi.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/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