mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andries Brouwer <aebr@win.tue.nl>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Greg KH <greg@kroah.com>, Andrey Borzenkov <arvidjaar@mail.ru>,
	linux-hotplug-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: removable media revalidation - udev vs. devfs or static /dev
Date: Thu, 8 Jan 2004 03:13:57 +0100	[thread overview]
Message-ID: <20040108031357.A1396@pclin040.win.tue.nl> (raw)
In-Reply-To: <Pine.LNX.4.58.0401071036560.12602@home.osdl.org>; from torvalds@osdl.org on Wed, Jan 07, 2004 at 10:38:31AM -0800

On Wed, Jan 07, 2004 at 10:38:31AM -0800, Linus Torvalds wrote:

> > Doesn't the kernel always create the main block device for this device?
> > If so, udev will catch that.
> 
> But udev should probably also create all the sub-nodes if it doesn't 
> already.
> 
> And it really has to create _all_ of them, exactly because there's no way
> to know ahead-of-time which of them will be available.
> 
> Then, user space can just access "/dev/sda1" or whatever, and the act of 
> accessing it will force the re-scan.

1. That is a bad idea.
2. There is no problem.

Ad 1)

- All, how many is that? 16? 64? more?
  Today IDE disks have 64 minors.

- I hate to think of the sysfs tree. Today I am unhappy already:
# ls /sys/block
.       nbd102  nbd116  nbd15  nbd29  nbd42  nbd56  nbd7   nbd83  nbd97  ram6
..      nbd103  nbd117  nbd16  nbd3   nbd43  nbd57  nbd70  nbd84  nbd98  ram7
fd0     nbd104  nbd118  nbd17  nbd30  nbd44  nbd58  nbd71  nbd85  nbd99  ram8
hda     nbd105  nbd119  nbd18  nbd31  nbd45  nbd59  nbd72  nbd86  ram0   ram9
hdb     nbd106  nbd12   nbd19  nbd32  nbd46  nbd6   nbd73  nbd87  ram1   sda
hdd     nbd107  nbd120  nbd2   nbd33  nbd47  nbd60  nbd74  nbd88  ram10  sdb
hde     nbd108  nbd121  nbd20  nbd34  nbd48  nbd61  nbd75  nbd89  ram11  sdc
hdf     nbd109  nbd122  nbd21  nbd35  nbd49  nbd62  nbd76  nbd9   ram12  sdd
hdg     nbd11   nbd123  nbd22  nbd36  nbd5   nbd63  nbd77  nbd90  ram13  sde
md0     nbd110  nbd124  nbd23  nbd37  nbd50  nbd64  nbd78  nbd91  ram14  sr0
nbd0    nbd111  nbd125  nbd24  nbd38  nbd51  nbd65  nbd79  nbd92  ram15
nbd1    nbd112  nbd126  nbd25  nbd39  nbd52  nbd66  nbd8   nbd93  ram2
nbd10   nbd113  nbd127  nbd26  nbd4   nbd53  nbd67  nbd80  nbd94  ram3
nbd100  nbd114  nbd13   nbd27  nbd40  nbd54  nbd68  nbd81  nbd95  ram4
nbd101  nbd115  nbd14   nbd28  nbd41  nbd55  nbd69  nbd82  nbd96  ram5

Someone decided to create "all" nbd devices.
If a similar thing is done for all disks then soon this directory will have
more nodes that current /dev.

Ad 2)
On the other hand, there is no need at all for udev or the kernel
to do anything special.
If hotplug and udev do their work, then the node for the whole device
is created.
Now the plan (or at least my plan) has always been to remove all
partition detection from the kernel. It can all be done from user space.
We have had the infrastructure for a long time, and it works.

So, it is trivial to create the utility parsept+mount that takes
a device, reads its partition table, tells the kernel about the
partitions found there, and mounts the desired partition.
It can be a mount option to do a parsept if the device does not
exist yet.

Andries


  parent reply	other threads:[~2004-01-08  2:14 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-01 20:33 Andrey Borzenkov
2004-01-03  5:58 ` Greg KH
2004-01-03  8:51   ` Andrey Borzenkov
2004-01-03 12:37     ` Andries Brouwer
2004-01-03 12:42       ` Olaf Hering
2004-01-03 16:05         ` Andrey Borzenkov
2004-01-03 17:54           ` Jens Axboe
2004-01-07  9:43             ` Olaf Hering
2004-01-07  9:50               ` Jens Axboe
2004-01-07  9:56                 ` Olaf Hering
2004-01-07  9:59                   ` Jens Axboe
2004-01-07 10:25                     ` Olaf Hering
2004-01-07 10:31                       ` Jens Axboe
2004-01-07 10:47                         ` Andrey Borzenkov
2004-01-07 10:54                           ` Jens Axboe
2004-01-07 17:56                       ` Greg KH
2004-01-30 12:59                     ` Olaf Hering
2004-01-07 11:00                 ` Andrey Borzenkov
2004-01-07 11:05                   ` Jens Axboe
2004-01-07 11:14                     ` Andrey Borzenkov
2004-01-07 11:16                       ` Jens Axboe
2004-01-03 20:51     ` Greg KH
2004-01-07 18:38   ` Linus Torvalds
2004-01-07 18:57     ` Greg KH
2004-01-07 19:23       ` Mika Penttilä
2004-01-07 19:24         ` Greg KH
2004-01-07 19:31           ` Mika Penttilä
2004-01-08  1:38           ` Linus Torvalds
2004-01-07 19:31       ` Linus Torvalds
2004-01-07 19:50         ` Greg KH
2004-01-07 20:25           ` Richard Troth
2004-01-07 20:38             ` Valdis.Kletnieks
2004-01-07 23:34             ` Greg KH
2004-01-08  0:32           ` Martin J. Bligh
2004-01-08  0:41             ` Greg KH
2004-01-08  1:07               ` Martin J. Bligh
2004-01-08  1:15                 ` Greg KH
2004-01-08  1:50                   ` Martin J. Bligh
2004-01-08 18:34                   ` Martin Schlemmer
2004-01-08  1:48           ` Linus Torvalds
2004-01-08 14:06           ` "Andrey Borzenkov" 
2004-01-08  0:42         ` viro
2004-01-08  1:16           ` Greg KH
2004-01-09  3:36       ` Joel Becker
2004-01-09  9:49         ` Gerd Knorr
2004-01-12 17:16           ` Joel Becker
2004-01-12 23:08             ` J.A. Magallon
2004-01-07 20:52     ` Olaf Hering
2004-01-08  2:03       ` Linus Torvalds
2004-01-08  4:16         ` Gene Heskett
2004-01-08  4:23           ` Linus Torvalds
2004-01-08  7:45         ` Olaf Hering
2004-01-08  2:13     ` Andries Brouwer [this message]
2004-01-08  2:19       ` Linus Torvalds
2004-01-08  2:49         ` Andries Brouwer
2004-01-08  2:56           ` Linus Torvalds
2004-01-08  3:35             ` Andries Brouwer
2004-01-08  3:43               ` Linus Torvalds
2004-01-08  8:00                 ` Xavier Bestel
2004-01-09  0:28                 ` Robert Love
2004-01-09  0:52                   ` Linus Torvalds
2004-01-09  1:16                   ` Matt Mackall
2004-01-08 10:32             `  Éric Brunet
2004-01-08  5:19 Iqbal
2004-01-12  9:09 Ling, Xiaofeng
2004-01-12 13:02 Nicolas Mailhot

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=20040108031357.A1396@pclin040.win.tue.nl \
    --to=aebr@win.tue.nl \
    --cc=arvidjaar@mail.ru \
    --cc=greg@kroah.com \
    --cc=linux-hotplug-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.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

all inboxes | Powered by JetHome®