lkml.org 
[lkml]   [1999]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.070 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site