Re: Getting past the 16-bit dev_t limitation.
On Mon, Sep 18, 2000 at 03:41:11PM -0700, John Byrne wrote:
> 1.) Any decision on what the bigger dev_t will be? 16-bit major and
> 16-bit minor, for example?
My old code does something like this:
major = (dev >> 32);
minor = (dev & 0x);
if (!major) {
major = (dev >> 16);
minor = (dev & 0x);
if (!major) {
major = (dev >> 8);
minor = (dev & 0xff);
}
}
In other words: If the whole thing is 16-bit, there is an 8-8
split. If the whole thing is 32-bit, there is a 16-16 split.
Etc.
This allows all the old device numbers to stay.
The present isofs code uses a similar algorithm.
In principle of course a device number is a structureless number,
but mknod needs it in two components, and ls lists it in two
components. Otherwise the partition does not play a role.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
"H. Peter Anvin" wrote: > > Followup to: <[EMAIL PROTECTED]> > By author:John Byrne <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Anyway, one of the things I was hoping to find out by going to > > linux-kernel was if there was anything other than devfs in the offing: > > such a larger dev_t. So if anyone wants to chime in on things other than > > devfs, I'd certainly like to hear about it. > > > > A larger dev_t is a "must have" item for 2.5. > > -hpa A couple of last details (sorry for being such a slug in following up): 1.) Any decision on what the bigger dev_t will be? 16-bit major and 16-bit minor, for example? 2.) Are there any plans to try to change the user dev_t to an opaque type? Grepping through the Redhat distribution's application sources reveals several things that compare major numbers determine the type of the device. (Some explictly hardcoded; others use the constants in linux/major.h, but compare several majors for IDE/SCSI.) To me, this kind of explicit knowledge compiled into applications is something to be avoided; even when there are relatively few applications that do this. Of course, there is a strong argument for KISS, here: most of these applications should work with a simple recompilation and the need for multiple majors will be reduced once the bigger dev_t is introduced. Thanks, John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
"H. Peter Anvin" wrote: Followup to: [EMAIL PROTECTED] By author:John Byrne [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Anyway, one of the things I was hoping to find out by going to linux-kernel was if there was anything other than devfs in the offing: such a larger dev_t. So if anyone wants to chime in on things other than devfs, I'd certainly like to hear about it. A larger dev_t is a "must have" item for 2.5. -hpa A couple of last details (sorry for being such a slug in following up): 1.) Any decision on what the bigger dev_t will be? 16-bit major and 16-bit minor, for example? 2.) Are there any plans to try to change the user dev_t to an opaque type? Grepping through the Redhat distribution's application sources reveals several things that compare major numbers determine the type of the device. (Some explictly hardcoded; others use the constants in linux/major.h, but compare several majors for IDE/SCSI.) To me, this kind of explicit knowledge compiled into applications is something to be avoided; even when there are relatively few applications that do this. Of course, there is a strong argument for KISS, here: most of these applications should work with a simple recompilation and the need for multiple majors will be reduced once the bigger dev_t is introduced. Thanks, John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
On Mon, Sep 18, 2000 at 03:41:11PM -0700, John Byrne wrote:
1.) Any decision on what the bigger dev_t will be? 16-bit major and
16-bit minor, for example?
My old code does something like this:
major = (dev 32);
minor = (dev 0x);
if (!major) {
major = (dev 16);
minor = (dev 0x);
if (!major) {
major = (dev 8);
minor = (dev 0xff);
}
}
In other words: If the whole thing is 16-bit, there is an 8-8
split. If the whole thing is 32-bit, there is a 16-16 split.
Etc.
This allows all the old device numbers to stay.
The present isofs code uses a similar algorithm.
In principle of course a device number is a structureless number,
but mknod needs it in two components, and ls lists it in two
components. Otherwise the partition does not play a role.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
"H. Peter Anvin" wrote: > > Followup to: <[EMAIL PROTECTED]> > By author:John Byrne <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Anyway, one of the things I was hoping to find out by going to > > linux-kernel was if there was anything other than devfs in the offing: > > such a larger dev_t. So if anyone wants to chime in on things other than > > devfs, I'd certainly like to hear about it. > > > > A larger dev_t is a "must have" item for 2.5. And devfs doesn't provide NOTHING to facilitate it... -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
Followup to: <[EMAIL PROTECTED]> By author:John Byrne <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Anyway, one of the things I was hoping to find out by going to > linux-kernel was if there was anything other than devfs in the offing: > such a larger dev_t. So if anyone wants to chime in on things other than > devfs, I'd certainly like to hear about it. > A larger dev_t is a "must have" item for 2.5. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
Matt Yourst wrote: > > > > >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, ... > > > This is the whole reason Linux 2.4 uses devfs (device filesystem) - > there is no need to use device numbers; you just register the name in > the /dev/whatever namespace and it's done. (The kernel will assign a > unique old-style 16-bit number for compatibility purposes as needed.) > See linux/Documentation/filesystems/devfs/README for the full story. > > - Matt Yourst Matt, Maybe I'm missing something, but I cannot find anything in the 2.4.0-test7 source which uses the DEVFS_FL_AUTO_DEVNUM flag; so it looks to me like all drivers are currently running with their old-style majors and minors. (I assume because there are applications out there that depend on them.) I don't deny devfs has the potential to do away with old style device numbers and their problems, but it does not seem to be currently used in that manner. At least some new drivers can presumably be written to take advantage of this feature since they may not have to worry about application compatibility. Anyway, one of the things I was hoping to find out by going to linux-kernel was if there was anything other than devfs in the offing: such a larger dev_t. So if anyone wants to chime in on things other than devfs, I'd certainly like to hear about it. Thanks, John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
Followup to: <[EMAIL PROTECTED]> By author:Matt Yourst <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > > > >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, ... > > > This is the whole reason Linux 2.4 uses devfs (device filesystem) - > there is no need to use device numbers; you just register the name in > the /dev/whatever namespace and it's done. (The kernel will assign a > unique old-style 16-bit number for compatibility purposes as needed.) > See linux/Documentation/filesystems/devfs/README for the full story. > This is a nice fable, but that's pretty much all it is. Your user space is going to puke all over you if you try to mess with this. The right solution, a larger dev_t, *WILL* be implemented in 2.5. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting 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, ... > This is the whole reason Linux 2.4 uses devfs (device filesystem) - there is no need to use device numbers; you just register the name in the /dev/whatever namespace and it's done. (The kernel will assign a unique old-style 16-bit number for compatibility purposes as needed.) See linux/Documentation/filesystems/devfs/README for the full story. - Matt Yourst - Matt T. YourstMassachusetts Institute of Technology [EMAIL PROTECTED] 617.225.7690 513 French House - 476 Memorial Drive - Cambridge, MA 02136 - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting 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, ... This is the whole reason Linux 2.4 uses devfs (device filesystem) - there is no need to use device numbers; you just register the name in the /dev/whatever namespace and it's done. (The kernel will assign a unique old-style 16-bit number for compatibility purposes as needed.) See linux/Documentation/filesystems/devfs/README for the full story. - Matt Yourst - Matt T. YourstMassachusetts Institute of Technology [EMAIL PROTECTED] 617.225.7690 513 French House - 476 Memorial Drive - Cambridge, MA 02136 - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
Followup to: [EMAIL PROTECTED] By author:Matt Yourst [EMAIL PROTECTED] In newsgroup: linux.dev.kernel 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, ... This is the whole reason Linux 2.4 uses devfs (device filesystem) - there is no need to use device numbers; you just register the name in the /dev/whatever namespace and it's done. (The kernel will assign a unique old-style 16-bit number for compatibility purposes as needed.) See linux/Documentation/filesystems/devfs/README for the full story. This is a nice fable, but that's pretty much all it is. Your user space is going to puke all over you if you try to mess with this. The right solution, a larger dev_t, *WILL* be implemented in 2.5. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
Matt Yourst wrote: 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, ... This is the whole reason Linux 2.4 uses devfs (device filesystem) - there is no need to use device numbers; you just register the name in the /dev/whatever namespace and it's done. (The kernel will assign a unique old-style 16-bit number for compatibility purposes as needed.) See linux/Documentation/filesystems/devfs/README for the full story. - Matt Yourst Matt, Maybe I'm missing something, but I cannot find anything in the 2.4.0-test7 source which uses the DEVFS_FL_AUTO_DEVNUM flag; so it looks to me like all drivers are currently running with their old-style majors and minors. (I assume because there are applications out there that depend on them.) I don't deny devfs has the potential to do away with old style device numbers and their problems, but it does not seem to be currently used in that manner. At least some new drivers can presumably be written to take advantage of this feature since they may not have to worry about application compatibility. Anyway, one of the things I was hoping to find out by going to linux-kernel was if there was anything other than devfs in the offing: such a larger dev_t. So if anyone wants to chime in on things other than devfs, I'd certainly like to hear about it. Thanks, John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
Followup to: [EMAIL PROTECTED] By author:John Byrne [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Anyway, one of the things I was hoping to find out by going to linux-kernel was if there was anything other than devfs in the offing: such a larger dev_t. So if anyone wants to chime in on things other than devfs, I'd certainly like to hear about it. A larger dev_t is a "must have" item for 2.5. -hpa -- [EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Getting past the 16-bit dev_t limitation.
"H. Peter Anvin" wrote: Followup to: [EMAIL PROTECTED] By author:John Byrne [EMAIL PROTECTED] In newsgroup: linux.dev.kernel Anyway, one of the things I was hoping to find out by going to linux-kernel was if there was anything other than devfs in the offing: such a larger dev_t. So if anyone wants to chime in on things other than devfs, I'd certainly like to hear about it. A larger dev_t is a "must have" item for 2.5. And devfs doesn't provide NOTHING to facilitate it... -- - phone: +49 214 8656 283 - job: STOCK-WORLD Media AG, LEV .de (MY OPPINNIONS ARE MY OWN!) - langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort: ru_RU.KOI8-R - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Getting past the 16-bit dev_t limitation.
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Getting past the 16-bit dev_t limitation.
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
