Re: PROPOSAL: /proc/dev
Richard Gooch (rgooch@atnf.CSIRO.AU)
Fri, 9 Jan 1998 11:40:03 +1100
ketil@ii.uib.no writes:
> Richard Gooch <rgooch@atnf.CSIRO.AU> writes:
>
> > You still need to stuff around allocating major&minor numbers. Part of
> > the motivation for this is to avoid that.
>
> I'm not convinced I understand what you mean. I mean, if you want to be
> able to boot non-devs-enabled kernels, you *do* need to have a regular
> /dev directory.
>
> And if you're sure you only will run devfs-enabled kernels, why, then
> you have the option to just make a dummy /dev directory with the right
> names/permissions etc.
>
> I'm not sure my point got across, which was to use the old /dev
> directory(ies) as configuration for the devfs, and then in turn use a
> devfs mount to "shadow" the /dev directory.
>
> > The semantics of adding entries (what happens if overlayfs is not
> > mounted yet and a driver "exposes" (installs) the /dev entries?) are
> > sufficiently complicated that you need a special-purpose devfs, IMHO.
>
> The way I pictured it, if you load a module, it will only register its
> device in the devfs - any old mknod'ed /dev directory won't see any
> difference, and nothing will actually happen to disk. Directories
> mounted as none -t devfs would see it (or not, depending on the
> configuration of the directory it shadows).
>
> Say I want to have some special purpose directory with a printer
> device. I could then, in /my/dev/ do an mknod to get a printer device
> file. It would work, as long as the appropriate functionality was
> present in the kernel.
>
> Now, mounting none -t devfs on top of /my/dev would show the device file
> iff the functionality was present, and no other device files, inheriting
> from the original directory.
>
> Would something like that be workable? It seems to me like a workable
> solution, but I might be blatantly ignoring lots of low-level issues, I
> know.
If I understand what you mean, there would be problems. Device drivers
which use devfs (in a devfs-enabled kernel) would *only* be accessible
through a mounted devfs. Other device drivers which are not yet
converted to be devfs-capable (i.e. with #ifdef CONFIG_DEVFS wrappers)
would *only* be accessible through the old disc-based c&b nodes.
The is an important difference between the way disc-based c&b nodes
and devfs make the connection between an entry in /dev and the actual
device driver.
For disc-based c&b nodes, the connection is done via a lookup table of
major and minor numbers. When you open such a node, the major table is
scanned for the matching major number and the open method for that
major is called. For miscellaneous character devices, there is another
scan for the minor number, and the appropriate minor open method is
called. This scanning is done *every time* you open a device node.
For devfs entries, the connection is done when you lookup the /dev
entry. When dev_register() was called, an internal table was 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'es which don't have them:-).
Note that the devfs doesn't use the major&minor system.
Regards,
Richard....