Re: Larger dev_t

[Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>]

On Mon, Apr 02, 2001 at 10:17:02PM +0200, Andries.Brouwer@cwi.nl 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
communication.

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
      spindles
   -  ...

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 inode1.media == inode2.media (one of the most
important uses for device numbers) we don't need to change
anything.

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
defintion.

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!

Regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
         <<<<<<<<<<<<     been there and had much fun   >>>>>>>>>>>>