Re: Migrating to larger numbers
H. Peter Anvin (hpa@transmeta.com)
Fri, 28 May 1999 22:39:32 -0700
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/