lkml.org 
[lkml]   [2000]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Getting past the 16-bit dev_t limitation.
Helge Hafting wrote:
>
> John Byrne wrote:
>
> > 1.) Can anyone tell me if there is a (Linus approved) solution in the
> > works for this for the 2.4.xx kernel series?
>
> > I am also curious whether there are plans to do away with the whole
> > concept of major/minor numbers;
>
> Consider reading up on devfs, which is now integrated into 2.4.
> Basically it is a (optional) special filesystem, where a driver register
> a
> name for each device it serves, possibly in a subdirectory.
> (I.e. all audio devices in /dev/sound/..., all scsi stuff under
> /dev/scsi/...)
>
> This device filesystem is mounted at /dev during boot, instead of having
> a
> /dev directory with special files.
>
> Helge Hafting

Both you and Martin told me to look as devfs. I had, but I looked again
to see what I had missed.

I had somehow missed that internally devfs allows majors and minors to
both be 16-bits. However, the interface to the kernel for this
information and thence to the user world is still looks to be the 16-bit
kdev_t; so exceeding 255 for your minor number would "bleed" onto your
major number and cause aliasing of devices in some cases. How bad the
effects would be, I don't know.

Thanks,

John
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

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