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/