Getting past the 16-bit dev_t limitation.

From: John Byrne (jbyrne@kahuna.cag.cpqcorp.net)
Date: Wed Sep 13 2000 - 17:50:14 EST


Hello,

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.

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/



This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:22 EST