Messages in this thread | | | From | ketil@ii ... | Subject | Re: PROPOSAL: /proc/dev | Date | 08 Jan 1998 11:57:47 +0100 |
| |
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.
~kzm -- If I haven't seen further, it is by standing in the footprints of giants
| |