Messages in this thread | | | Date | Fri, 28 May 1999 22:39:32 -0700 | From | "H. Peter Anvin" <> | Subject | Re: Migrating to larger numbers |
| |
Guest section DW wrote: > > From hpa@transmeta.com Sat May 29 02:41:14 1999 > > > > dev_t: 32 bits minimum, suggest 64 bits > > > > > Recall that uid_t, gid_t and dev_t both have -1 (0xffff) reserved > > > in a 16-bit environment; > > > > This suggests a particular way of going to a larger dev_t. > > > > I have been using (and am using a kernel like this right now): > > > > static inline kdev_t to_kdev_t(dev_t dev) > > { > > int major, minor; > > > > major = (dev >> 32); > > if (!major) { > > major = (dev >> 16); > > if (!major) { > > major = (dev >> 8); > > minor = (dev & 0xff); > > } else > > minor = (dev & 0xffff); > > } else > > minor = (dev & 0xffffffff); > > > > return MKDEV(major, minor); > > } > > > > I am not aware of any disadvantages of this system, > > although, now that I think about it, the fact that > > multiple representations yield the same (major,minor) > > has both advantages and disadvantages. > > So far I have not encountered real problems. > > A much worse error is that it relies on zero, not -1. Zero is not a > reserved device number; in fact, it has special meaning. > > Hmm. I think I disagree. > The above code does not rely on any particular number. > It just says that if the device number fits into 16 bits > then it is partitioned into major and minor in a particular way, > and if not it is partitioned in some other way.
And so how do you distinguish between (0,2000) and (7,208)?
-hpa
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |