[lkml]   [2001]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Larger dev_t
On Mon, Apr 02, 2001 at 10:17:02PM +0200, wrote:
> What is dev_t used for? It is a communication channel from
> filesystem to user space (via the stat() system call)
> and from user space to filesystem (via the mknod() system call).

The question is WHAT do we communicate (and don't answer "major
minor" here, since this is only numbers) and WHY do we need this

Devfs aims to associate device names with dynamic, flat device
numbers. So we have a scalable solution for the kernel -> user
space communication. What we DON't have, is a similar simple way
to tell it the other way around.

The reasons, why we need to know where a file is located on are:
- to only include files from one media
- to run certain optimizations like fsck does with disk
- ...

So instead of just shifting the problems into the future and
making the same mistake again, we should better think of
interfaces, that give us the information we need and let this
error prone (ever had a typo on mknod?) and never large enough
static interface die.

Maybe there should be a way to translate a dynamic associated
device number into a real device name, like the devfs name of it.
May be a reverse mapping in devfs (/dev/by_dev_no/[0-9]+) would
work. If these are symlinks, a readlink() would suffice. Very
simple solution.

For comparing == (one of the most
important uses for device numbers) we don't need to change

For getting the device number of the spindle, the block devices
which support partitions or are remapping a (set of) block
device(s) could get IOCTLs (where this information belongs into
and is as reliable as the driver).

For all these things, we can have a flat and dynamic device
number namespace.

Device numbers have to be uniqe only during one power on -> run ->
power off cycle. For the rest applications should store device
names instead anyway. The applications, that don't are buggy by

Note: I certainly overlooked sth., so please flame me ;-)

> The current discussion is almost entirely about mknod.]

Yes: Let "mknod /dev/foo [bc] x y" die!


Ingo Oeser
10.+11.03.2001 - 3. Chemnitzer LinuxTag <>
<<<<<<<<<<<< been there and had much fun >>>>>>>>>>>>
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.086 / U:2.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site