[lkml]   [2000]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectGetting past the 16-bit dev_t limitation.

I am working on a project that is going to find the current limit of
16-bits for device numbers to be a pain. While looking around in the
linux-kernel archive, I found a series of e-mails about this from late
last year in which was discussed the introduction of the kdev_t type
and the possible future plans for it. I've also seen from the kdev_t.h
file that the type was introduced in 1995; so it doesn't appear that
there has been a big hurry to do anything. So:

1.) Can anyone tell me if there is a (Linus approved) solution in the
works for this for the 2.4.xx kernel series?

The "kdev_t as a pointer" concept looks interesting.

I am also curious whether there are plans to do away with the whole
concept of major/minor numbers; the user-mode dev_t would just be a
unique number for a specific device with no meaning beyond that. devfs
could be used to auto-assign them as drivers register devices, perhaps.

2.) Can anyone offer advice or a pointer to patches other people have
worked on?

Given that glibc presents the user with a larger dev_t already, it seems
possible to me that we should be able to modify the kernel to support a
32-bit kdev_t with perhaps only changing glibc in user-space. I know
there would be holes, but it might be good enough for our purposes for
now without representing a horrible maintenance problem.

Please cc any replies to me directly as read the list via the archive.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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