LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   devfs max major/minor numbers (https://www.linuxquestions.org/questions/linux-newbie-8/devfs-max-major-minor-numbers-66269/)

devershetty 06-17-2003 09:18 PM
devfs max major/minor numbers
 
Hi All..

As of now Linux kernel supports 8 bits for Major and 8 bits for minor numbers ...but using devfs support for Linux kernel is it possible to increase this limit???
i need to support 1024 devices using one major number ? how?

-thanks in advacne.
-Kotresh.

moses 06-17-2003 09:37 PM
devfs doesn't do its thing using Major and minor numbers, those are there just for backward compatibility.
From the kernel documentation, /usr/src/linux/Documentation/filesystems/devfs/README:
Quote:

Linux *must* move beyond the 8 bit major and minor barrier,
somehow. If we simply increase each to 16 bits, then the indexing
scheme used for major driver lookup becomes untenable, because the
major tables (one each for character and block devices) would need to
be 64 k entries long (512 kBytes on x86, 1 MByte for 64 bit
systems). So we would have to use a scheme like that used for
miscellaneous character devices, which means the search time goes up
linearly with the average number of major device drivers on your
system. Not all "devices" are hardware, some are higher-level drivers
like KGI, so you can get more "devices" without adding hardware
You can improve this by creating an ordered (balanced:-)
binary tree, in which case your search time becomes log(N).
Alternatively, you can use hashing to speed up the search.
But why do that search at all if you don't have to? Once again, it
seems pointless.

Note that devfs doesn't use the major&minor system. For devfs
entries, the connection is done when you lookup the /dev entry. When
devfs_register() is called, an internal table is appended which has
the entry name and the file_operations. If the dentry cache doesn't
have the /dev entry already, this internal table is scanned to get the
file_operations, and an inode is created. If the dentry cache already
has the entry, there is *no lookup time* (other than the dentry scan
itself, but we can't avoid that anyway, and besides Linux dentries
cream other OS's which don't have them:-). Furthermore, the number of
node entries in a devfs is only the number of available device
entries, not the number of *conceivable* entries. Even if you remove
unnecessary entries in a disc-based /dev, the number of conceivable
entries remains the same: you just limit yourself in order to save
space.


All times are GMT -5. The time now is 11:32 PM.