> Not so -- the driver is always determined by some number of
> left-associated bits (like an IP route); ideally it should always be the
> major number.
> I am proposing a 32/32 split (with a 12/20 split for NFSv2), because
> glibc already is using a 64-bit dev_t. Adding thousands of modems
> therefore is not a problem, and I believe it would be very hard to
> construct a scenario at which this will not be sufficient for a very
> long time.
Take sample from devfs FAQ, add USB and you'll got:
USB bus number -- 3bit
USB device number -- 8+4bit
channel -- 4bit
id -- 4bit
lun -- 3bit
partition -- 6bit
TOTAL -- 32bit
It's 32bit for minor number already ! With existing technologies ! And who
knows how much will need the future ? The problem with major/minor approach
is that you should number all possible devices ever connectable to your host.
Even if it's highly unlikely to have even 65536 devices (to overflow current
8bit/8bit major/minor pair) it's higly likely for tree-like buses to overflow
32bit/32bit major/minor pair in not so distant future. Yes, just a REALLY tiny
part of such giant namespace will be used on each particular computer but
namespace for all computers will not fit in 64bits really soon. And to have
static allocation of major/minor numbers you must different names for them
all :-/ IMHO the only sane way to handle all this is to use arbitraty
strings to name devices...
P.S. You can say: let's name devices by functions not by placement. It's
usefull in some situations, while not in others. It's work for userspace
daemon, not for kernel to make such decisions. Take a look on SCSI: it uses
such approach right now and while it works perfect sometimes in some other
cases flat SCSI namespace of current kernel is real PITA :-((
-
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/