Messages in this thread | | | Date | Wed, 6 Oct 1999 20:49:50 -0500 (CDT) | From | Peter Samuelson <> | Subject | Re: USB device allocation |
| |
[Peter Samuelson <sampo.creighton.edu!psamuels>] > > And before you complain that this breaks compatibility with someone > > (LILO and rdev need to be taught not to hardcode root dev numbers > > in), remember that a bigger kdev_t carries the same disadvantage. [Riley Williams] > There appears to be several people claiming that a bigger kdev_t > breaks compatibility with lots of programs, and I find this rather > hard to understand, so can somebody explain this to me please?
Well, people may be saying it but I'm not one. I said it would break compatibility with "someone" and I personally think it's a non-issue. Expanding my example above, both LILO and rdev rely on a kernel ABI which specifies a 16-bit place to put a root device number. This would have to be modified, and LILO and rdev would by necessity break. (At least rdev breaks. LILO can be tricked into using a command line for root device by judicious use of "append=". This from Richard's devfs FAQ -- since the same issue comes up with "devfs=nocompat".)
> In particular, please explain what's wrong with implementing a 32-bit > or 64-bit kdev_t defined such that nodes where all except the bottom > 16 bits are zero, it is defined as a "compatibility node"?
Nothing wrong with it at all, except the small amount of necessary code bloat. This bloat is no doubt negligible but I mention it because bloat is the only argument against devfs that I buy at this point. Perhaps the bloat of 32-(or 64-)bit dev numbers can be considered the Lesser Satan, as compared to devfs, the Greater Satan. (:
-- Peter Samuelson <sampo.creighton.edu!psamuels>
- 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/
| |