Messages in this thread | | | Date | Fri, 7 Dec 2001 16:07:34 -0700 | From | Erik Andersen <> | Subject | Re: On re-working the major/minor system |
| |
On Fri Dec 07, 2001 at 02:04:42PM -0800, H. Peter Anvin wrote: > > It's clear a painful change is needed. **We don't have a choice.** > However, the fewer places we have to make source code changes the better.
Sure. I'm not arguing again the change. Just making sure everyone 100% understands that we have just thown any prayer of binary compatibility with anything less then 2.5.x....
But lets look on the bright side though. Since we are going to be having a flag day _anyways_ we may as well make the most of it. I can think of 20 things off the top of my head that are being retained in the name of binary cmpatibilty that can easily move to the trash bucket. :)
For example, I would _love_ for Linux to standardize syscall numbers across all architectures, guarantee that userspace gets the exact same stack setup for all arches, we might as well fixup proc, etc, etc, etc.
> What we agreed upon when this was discussed last year was the following: > > dev_t is extended to a 12:20 (32-bit size.) I personally would rather > have seen a 64-bit size (32:32) but was outvoted :( > > New major 0 is reserved, except that dev_t == 0 remains the code for "no > device". The unnamed device major becomes major 256. > > If (dev_t & ~0xFFFF) == 0, the dev_t is interpreted as an old-format > dev_t, and is interpreted according to the following algorithm: > > if ( dev && (dev & ~0xFFFF) == 0 ) { > major = (dev >> 8) ? (dev >> 8) : 256; > minor = dev & 0xFF; > } else { > major = dev >> 20; > minor = dev & 0xFFFFF; > }
That works, and should prevent most major problems. Hmm. At least for cpio there are 6 chars worth of device info in there, so we coule easily go to 48 bits without RPM problems. Or redhat could fix rpm to use tarballs like debs do, and then we could go to 64 bit devices no problem.
-Erik
-- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |