From: Olaf Hering <olh@suse.de>
To: viro@parcelfarce.linux.theplanet.co.uk
Cc: Rob Love <rml@ximian.com>, Nathan Conrad <lk@bungled.net>,
Pascal Schmidt <der.eremit@email.de>,
linux-kernel@vger.kernel.org, Greg KH <greg@kroah.com>
Subject: Re: udev and devfs - The final word
Date: Wed, 7 Jan 2004 11:15:59 +0100 [thread overview]
Message-ID: <20040107101559.GA22770@suse.de> (raw)
In-Reply-To: <20031231225536.GP4176@parcelfarce.linux.theplanet.co.uk>
On Wed, Dec 31, viro@parcelfarce.linux.theplanet.co.uk wrote:
> On Wed, Dec 31, 2003 at 05:20:18PM -0500, Rob Love wrote:
> > On Wed, 2003-12-31 at 17:01, Nathan Conrad wrote:
> > Uh, Unix systems (Linux included) do not use the filename of the device
> > node at all. Those are just names for you, the user.
> >
> > The kernel uses the device number to understand what device user-space
> > is trying to access. The kernel associates the device with a device
> > number. Normally that number is static, and known a priori, so we just
> > create a huge /dev directory with all possible devices and their
> > assigned numbers (you can see these numbers with ls -la).
> >
> > But if the kernel _tells_ user-space what the device number is, for each
> > device as it is created, we do not need a static /dev directory. We can
> > assemble the directory on the fly and device numbers really no longer
> > matter. This is what udev does.
>
> I think you've missed a point here. There are several places where kernel
> deals with device identification.
> a) when normal pathname lookup results in a device node on filesystem.
> That's the regular way.
> b) when we create a new device node; device number is passed to
> ->mknod() and new device node is created. Also a normal codepath.
> c) when late-boot code mounts the final root. It used to be black
> magic, but these days it's done by regular syscalls. Namely, we parse the
> "device name" (most of the work is done by lookups in sysfs), do mknod(2)
> and mount(2). It's still done from the kernel mode, but it could be moved
> to userland. Should be, actually.
> d) when kernel deals with resume/suspend stuff. Currently - black
> magic. Should be moved to early userland (same parser as for final root
> name + mknod on rootfs + open() to get the device in question).
> e) in several pathological syscalls we pass device number to
> identify a device. ustat(2) and its ilk - bad API that can't die.
> f) /dev/raw passes device number to bind raw device to block device.
> Bad API; we probably ought to replace it with saner one at some point.
> g) RAID setup - mix of both pathologies; should be done in userland
> and interfaces are in bad need of cleanup.
> h) nfsd uses device number as a substitute for export ID if said
> ID is not given explicitly. That, BTW, is a big problem for crackpipe
> dreams about random device numbers - export ID _must_ be stable across
> reboots.
> i) mtdblk parses "device name" on boot; should be take to early
> userland, same as RAID et.al.
This is about the /proc/self/mounts format:
Why does it contain stuff like "/dev/root" or "/dev/sda3" or
"/dev/myblockdevice"? Does anyone __really__ care about it? I doubt
that. What I have here (with 2.4) is:
olh@melon:~> cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw 0 0
proc /proc proc rw 0 0
devpts /dev/pts devpts rw 0 0
/dev/vg_melon/abuild /abuild ext3 rw 0 0
/dev/vg_melon/data1 /data1 ext3 rw 0 0
/dev/vg_melon/data2 /data2 ext3 rw 0 0
shmfs /dev/shm shm rw 0 0
automount(pid937) /suse autofs rw 0 0
wotan:/real-home/jplack /suse/jplack nfs rw,nosuid,v3,rsize=8192,wsize=8192,hard,intr,tcp,nolock,addr=wotan 0 0
wotan:/real-home/olh /suse/olh nfs rw,nosuid,v3,rsize=8192,wsize=8192,hard,intr,tcp,nolock,addr=wotan 0 0
Now, thats just fine and it was always been that way.
What if I chroot into /foo, proc is mounted on /foo/proc,
and run fsck /dev/sda3 in that chroot?
That silly app looks for /etc/mtab (oh my...) and start the work.
Fine. Now, /dev/root is in reality /dev/sda3. Bad for me.
the whole thing would work as expected of /proc/self/mounts would have
a sane format:
olh@melon:~> cat /proc/mounts
0:0 / rootfs rw 0 0
8:3 / ext3 rw 0 0
proc /proc proc rw 0 0
devpts /dev/pts devpts rw 0 0
58:0 /abuild ext3 rw 0 0
58:1 /data1 ext3 rw 0 0
58:2 /data2 ext3 rw 0 0
shmfs /dev/shm shm rw 0 0
automount(pid937) /suse autofs rw 0 0
wotan:/real-home/jplack /suse/jplack nfs rw,nosuid,v3,rsize=8192,wsize=8192,hard,intr,tcp,nolock,addr=wotan 0 0
wotan:/real-home/olh /suse/olh nfs rw,nosuid,v3,rsize=8192,wsize=8192,hard,intr,tcp,nolock,addr=wotan 0 0
Now fsck could look for /dev/sda3, realize that it is a block
device node and look for that in the kernel mount table.
If it is mounted, abort with a nice and meaningful error message.
So my question is: why was this strange format invented in the first place?
And: will 2.7 get a sane /proc/self/mounts format for block devices?
--
USB is for mice, FireWire is for men!
sUse lINUX ag, nÜRNBERG
next prev parent reply other threads:[~2004-01-07 10:16 UTC|newest]
Thread overview: 169+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <18Cz7-7Ep-7@gated-at.bofh.it>
2003-12-31 3:05 ` udev and devfs - The final word Pascal Schmidt
2003-12-31 19:23 ` Greg KH
2003-12-31 20:19 ` Rob Love
2003-12-31 22:01 ` Nathan Conrad
2003-12-31 22:20 ` Rob Love
2003-12-31 21:45 ` Tommi Virtanen
2003-12-31 23:10 ` Rob Love
2003-12-31 21:52 ` Tommi Virtanen
2004-01-02 0:17 ` Hollis Blanchard
2004-01-02 0:36 ` viro
2004-01-03 6:04 ` Greg KH
2003-12-31 22:55 ` viro
2003-12-31 23:05 ` Rob Love
2003-12-31 23:48 ` Andreas Dilger
2004-01-07 10:15 ` Olaf Hering [this message]
2004-01-07 11:18 ` viro
2004-01-07 13:00 ` Olaf Hering
2004-01-07 13:26 ` viro
2004-01-07 13:27 ` Olaf Hering
2004-01-01 0:15 ` Andries Brouwer
2004-01-01 0:31 ` Rob Love
2004-01-01 12:34 ` Rob Landley
2004-01-01 15:22 ` Rob Love
2004-01-01 15:48 ` Andries Brouwer
2004-01-01 15:54 ` Rob Love
2004-01-02 20:42 ` Linus Torvalds
2004-01-03 3:00 ` Andries Brouwer
2004-01-03 4:46 ` Linus Torvalds
2004-01-03 13:10 ` Andries Brouwer
2004-01-03 22:27 ` Linus Torvalds
2004-01-03 23:08 ` Andries Brouwer
2004-01-04 1:16 ` Mark Mielke
2004-01-04 1:54 ` Valdis.Kletnieks
2004-01-04 18:44 ` Mark Mielke
2004-01-04 2:09 ` Linus Torvalds
2004-01-04 2:49 ` Andries Brouwer
2004-01-04 3:04 ` Linus Torvalds
2004-01-04 4:36 ` Pentium 4 HT SMP Ananda Bhattacharya
2004-01-04 5:55 ` Martin J. Bligh
2004-01-04 13:21 ` udev and devfs - The final word Andries Brouwer
2004-01-04 21:05 ` Linus Torvalds
2004-01-04 22:01 ` Andries Brouwer
2004-01-04 22:37 ` viro
2004-01-05 1:02 ` Mark Mielke
2004-01-05 2:24 ` Valdis.Kletnieks
2004-01-05 2:29 ` Andries Brouwer
2004-01-05 3:42 ` viro
2004-01-04 22:37 ` Helge Hafting
2004-01-04 23:35 ` Valdis.Kletnieks
2004-01-05 1:43 ` Jeremy Maitin-Shepard
2004-01-05 1:47 ` st_dev:st_ino (was: Re: udev and devfs - The final word) Mark Mielke
2004-01-05 2:02 ` st_dev:st_ino Jeremy Maitin-Shepard
2004-01-05 3:14 ` st_dev:st_ino viro
2004-01-05 1:58 ` udev and devfs - The final word viro
2004-01-05 2:12 ` Jeremy Maitin-Shepard
2004-01-05 2:52 ` Linus Torvalds
2004-01-05 3:06 ` David Lang
2004-01-05 3:48 ` Rob Landley
2004-01-05 4:52 ` Trond Myklebust
2004-01-05 7:03 ` [offtopic] " Rob Landley
2004-01-05 12:07 ` Trond Myklebust
2004-01-05 15:13 ` Mark Mielke
2004-01-05 16:36 ` Andreas Schwab
2004-01-05 22:18 ` Mark Mielke
2004-01-05 3:07 ` Daniel Jacobowitz
2004-01-05 3:33 ` Linus Torvalds
2004-01-05 3:50 ` viro
2004-01-05 4:02 ` Linus Torvalds
2004-01-05 4:38 ` viro
2004-01-05 4:52 ` Linus Torvalds
2004-01-05 6:11 ` viro
2004-01-05 7:47 ` Greg KH
2004-01-05 11:15 ` Vojtech Pavlik
2004-01-05 20:11 ` Theodore Ts'o
2004-01-05 21:06 ` Vojtech Pavlik
2004-01-05 22:22 ` Theodore Ts'o
2004-01-06 0:14 ` Rob Landley
2004-01-06 17:28 ` [OT] " Disconnect
2004-01-11 22:12 ` Ed L Cashin
2004-01-05 5:26 ` Eric W. Biederman
2004-01-05 7:39 ` Greg KH
2004-01-07 9:57 ` Pavel Machek
2004-01-05 12:27 ` Andries Brouwer
2004-01-05 16:13 ` Linus Torvalds
2004-01-05 17:29 ` Vojtech Pavlik
2004-01-05 17:33 ` Linus Torvalds
2004-01-05 17:52 ` Davide Libenzi
2004-01-05 18:03 ` Linus Torvalds
2004-01-05 18:09 ` Hugo Mills
2004-01-05 19:10 ` Paul Rolland
2004-01-05 19:52 ` Andries Brouwer
2004-01-05 20:38 ` Linus Torvalds
2004-01-05 22:17 ` Shawn
2004-01-05 22:25 ` Mark Mielke
2004-01-05 23:05 ` Shawn
2004-01-05 23:23 ` Shawn
2004-01-06 0:43 ` Greg KH
2004-01-06 0:53 ` Shawn
2004-01-05 23:13 ` Andries Brouwer
2004-01-05 23:32 ` Linus Torvalds
2004-01-06 0:59 ` viro
2004-01-06 1:17 ` Linus Torvalds
2004-01-06 4:28 ` viro
2004-01-06 5:07 ` Linus Torvalds
2004-01-06 1:06 ` Andries Brouwer
2004-01-06 15:00 ` Mark Mielke
2004-01-06 0:00 ` Greg KH
2004-01-06 1:41 ` Andries Brouwer
2004-01-07 17:14 ` Greg KH
2004-01-06 0:31 ` Rob Landley
2004-01-06 7:14 ` Vojtech Pavlik
2004-01-06 0:36 ` Silly udev script [was Re: udev and devfs - The final word] Greg KH
2004-01-05 7:44 ` udev and devfs - The final word James H. Cloos Jr.
2004-01-05 7:45 ` Nigel Cunningham
2004-01-05 11:01 ` Robin Rosenberg
2004-01-05 12:39 ` Nigel Cunningham
2004-01-05 14:31 ` IRQ disabled on linux 2.6.1-rc1-mm1 Mainak Mandal _00007001_
2004-01-07 13:39 ` udev and devfs - The final word Robin Rosenberg
2004-01-07 17:16 ` Nigel Cunningham
2004-01-05 9:06 ` Valdis.Kletnieks
2004-01-05 4:15 ` Peter Chubb
2004-01-05 4:42 ` Linus Torvalds
2004-01-03 18:34 ` Wrapping jiffies [was Re: udev and devfs - The final word] Pavel Machek
2004-01-01 19:43 ` udev and devfs - The final word Kai Henningsen
2004-01-02 7:26 ` Rob Landley
2004-01-04 8:57 ` Greg KH
2004-01-04 9:43 ` Rob Landley
2004-01-02 0:17 ` Maciej Zenczykowski
[not found] ` <20040102103104.GA28168@mark.mielke.cc>
2004-01-03 6:07 ` Greg KH
2004-01-03 6:51 ` Valdis.Kletnieks
2004-01-03 11:57 ` Ian Kent
2004-01-03 22:08 ` Greg KH
2004-01-07 10:23 ` Olaf Hering
2004-01-01 23:14 ` Rob
2004-01-02 3:53 ` Tyler Hall
2004-01-01 16:17 ` Pascal Schmidt
2004-01-01 20:03 ` Greg KH
2004-01-08 13:53 "Andrey Borzenkov"
2004-01-08 15:40 ` Ian Kent
2004-01-08 17:26 ` Diego Calleja
2004-01-08 19:25 ` Andrey Borzenkov
2004-01-08 22:40 ` Alex Goddard
2004-01-09 7:03 ` "Andrey Borzenkov"
2004-01-08 18:14 ` Alex Goddard
2004-01-08 18:35 ` Alex Goddard
2004-01-08 19:22 ` Andrey Borzenkov
2004-01-09 8:51 ` Helge Hafting
-- strict thread matches above, loose matches on Subject: below --
2004-01-08 13:05 "Andrey Borzenkov"
2004-01-06 1:20 Paul Zimmerman
[not found] <fa.flhsork.uka2hg@ifi.uio.no>
[not found] ` <fa.hv9hpq7.1l1q9p3@ifi.uio.no>
2004-01-01 19:53 ` walt
2004-01-01 21:53 ` Martin Schlemmer
2004-01-01 16:59 Shaheed
[not found] <fa.af64864.ugabhg@ifi.uio.no>
[not found] ` <fa.de7jae9.1jk0pjt@ifi.uio.no>
2003-12-31 22:17 ` walt
2004-01-01 2:03 ` Martin Schlemmer
2004-01-01 2:05 ` Martin Schlemmer
2003-12-31 0:29 Greg KH
2003-12-31 0:53 ` Prakash K. Cheemplavam
2003-12-31 19:17 ` Greg KH
2004-01-02 16:45 ` Shawn
2003-12-31 12:43 ` Paulo Marques
2004-01-01 1:18 ` Helge Hafting
2004-01-03 5:59 ` Greg KH
2004-01-03 15:22 ` Helge Hafting
2004-01-03 21:18 ` viro
2004-01-03 22:11 ` Greg KH
[not found] ` <20040103140140.3b848e9f.witukind@nsbm.kicks-ass.org>
2004-01-03 22:16 ` Greg KH
2004-01-03 22:33 ` Christoph Hellwig
2004-01-02 17:54 ` Andreas Jellinghaus
2004-01-02 18:19 ` Shawn
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=20040107101559.GA22770@suse.de \
--to=olh@suse.de \
--cc=der.eremit@email.de \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lk@bungled.net \
--cc=rml@ximian.com \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/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).