Messages in this thread | | | From | "Khimenko Victor" <> | Date | Mon, 11 Oct 1999 10:05:11 +0400 (MSD) | Subject | Re: My $0.02 on devd and devfs |
| |
In <3801682B.E5118A2E@transmeta.com> H. Peter Anvin (hpa@transmeta.com) wrote: > Johannes Erdfelt wrote: >> >> Thanks for putting forth your input into the matter. >> >> I'd like to here your thoughts on major/minor allocation for PnP >> devices. The hypothetical example being used is connecting 1000+ modems >> to a machine. (Apparentely someone has done this on an Irix machine >> further solidifying the fact this can and will happen). >> >> Right now, it's impossible to do with the current 8/8 split of >> major/minor. Some people are proposing increasing it a 16/16 split which >> will significantly improve the situation, but as we've fallen into in >> the past, any arbitrary limit will be broken. >> >> Do you think simply increasing the major/minor will solve the problem? >> It seems like when you increase the major/minor space you also increase >> computational complexity in determining which driver owns that >> major/minor. >>
> 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/
| |