Messages in this thread | | | Date | Fri, 9 Jan 1998 11:40:03 +1100 | From | Richard Gooch <> | Subject | Re: PROPOSAL: /proc/dev |
| |
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....
| |