I think they allocate 32-bit device numbers dynamically.
They will never run out of device numbers for anything.
> Here are some reasons why people have wanted a "dev-fs" system.
>
> 1. Number of entries. I've just looked at my system and I have
> well over 650 entries and I have nothing special on system.
Yes. The directory search can be slow and it confuses newbies.
(I have a modem, it says so in /dev...)
> 2. Many unused entries. A standard setup will create many entries,
> even though you don't need them. Having unused entries affects
> the lookup of /dev.
>
> 3. When accessed, the atime on the /dev file will be updated. This means
> that when null, zero etc. is used, an update of the atime is required,
> this may not cause a significant impact, however, the atime on the /dev
> file does not provide any useful information. There is currently a
> patch around can prevent these updates, however these are primarily to
> help programs like news servers, and IMHO are only a workaround for
> resolving the /dev issue.
>
> 4. One of the items mentioned in the FSSTND stated the idea of
> having a read-only root FS. The idea was to reduce the problem
> of root FS corruption and not being able to recover from it
> without re-installation (MS method of recovery). Having a
> read-only FS affects the ability to change attributes such as
> ownership of tty files.
The current /dev could be trouble for Linux in ROM.
> 5. Maintenance of the /dev doesn't occur frequently, but when it
> does then it's up to the system administrator to resolve the
> synchronisation between major/minor numbers the kernel has the
> drivers at and what has been stored on the filesystem.
For those that don't see a problem here, consider that many versions
of Slackware had hdc* and hdd* messed up.
6. Reduced overhead for umsdos.
7. NTFS as the root filesystem.
8. pty security - the kernel can chown ptys back to root when a process
does not need them anymore. The kernel might be able to let normal
users chmod their own pty or perform the chown automatically.
> - Similiarities with proc fs.
>
> The majority (if not all) of Linux users use the proc filesytem,
> as it provides a lot of useful system information in a easily
> readable fashion. As such, hooks into functions based on existing
> lookup tables can be created off a procfs entry.
I don't think the devfs should be part of procfs. They might be
able to share some code though.
> - Kernel bloating.
>
> This is the only reason I've seen against the idea of the devfs,
> and this is certainly an issue to be concerned with. Although
> I've used the term devfs, It doesn't mean a completely different
> FS to procfs but more likely a integral part of it.
There are always tradeoffs. When Linus created Linux, he chose the
386 as the minimum hardware. While it would be nice to run standard
Linux on the 286, doing so would mean the rest of us must suffer.
Those people who can't use devfs because of memory limitations should
keep using the unofficial 1.2.14 with a.out and the minix filesystem.
Look at what ID software does: Quake requires a Pentium with about
16 MB of RAM. They know that designing software for obsolete hardware
will make the software obsolete. BTW, NT 4.0 needs a Pentium with
32 MB of RAM, and even Microsoft admits to a 486 with 12 MB of RAM.
> - Handling of loadable modules.
>
> Currently when an access to a /dev file occurs, and the driver
> associated with the major/minor numbers doesn't exist, the kernel
> asks kerneld to load it. This scheme won't work with missing dev
> entries. If we create a specific proc_lookup wrapper (like in
> root.c) for the dev directory and cater for the case ENOENT to
> request_module. All that needs to be done would be an interface
> to enable modules (and compiled in drivers) to register themselves
> with the kernel with names to be placed in dev, eg floppy.o could
> register fd0, fd0...
>
> An advantage with this is that you would only have dev entries
> for devices you currently have loaded.
The devfs can do module requests by name.
- Symlinks, rm, ...
Symlinks can be stored. Removed device files can just get
removed, though perhaps it is _good_ to prevent removal.
> - Compatibilties with existing Unix-like systems.
>
> It wouldn't be impossible to implement a /proc/dev to allow
> the above mechanism, but most Unix-people assume things
> like /dev/null. This could be addressed in two ways.
>
> ln -s /proc/dev /dev
Not good. The devfs can be separate from proc.
> or a more complicated solution would be to have the procfs
> mounted / initially (with /dev /system /proc hanging off it)
> and then perform some kind of transparent mount the rootfs
> (without a /dev /proc .. ) on top of /. therfore providing
> /sbin /etc /dev /proc /system whatever.
Interesting. That might make the initrd stuff work better because
there would be no need to mount, unmount, and remount /proc.