Messages in this thread | | | Date | Wed, 12 Aug 1998 07:42:14 +1000 (EST) | From | Nathan Hand <> | Subject | Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???) |
| |
On Tue, 11 Aug 1998, Theodore Y. Ts'o wrote:
> Date: Sat, 8 Aug 1998 21:35:28 +1000 > From: Richard Gooch <Richard.Gooch@atnf.CSIRO.AU> > > The reason I think that persistence is a side issue is because adding > it will not change the API nor the way the devfs internal management > is done. However, I expect we'll continue to disagree on this point. > That said, I'd rather look to the future. I'm currently considering > two options for persistence: > > - using a block device > > - peeking through to the underlying disc-based inodes. > > Ted, do you have any particular preferences/suggestions on this? > > My preference would be to store the inodes in the filesystem. If you're > going to be using a user mode daemon anyway, as you've suggested in > other mail messages, then let's define a well-defined interface for the > kernel to notify the user mode daemon that new devices has apeeared > (either at boot time or due to a PCMCIA/USB/1384 device getting > inserted), so that the user mode daemon can create the devices as > necessary.
I like this suggestion. It opens the door to having an /etc/dev.conf with permissions, ACLs, post-scripts, user-defined naming schemes (I think that would solve most people's problems immediately :-).
But isn't this remarkably similar to the kerneld idea?
I especially like the idea that modules still notify something there is a need for a /dev - so /dev remains dynamic, only shows you those devices which exist, etc - but very little exists in the kernel.
> This follows the fundamental principal of keeping policy out of the > kernel (an argument which you yourself have advanced), and doing as much > as possible in usermode. Performance won't be an issue, since if the > user-mode daemon is automatically creating the devices, you won't have > "8 million devices" in /dev (despite that favoriate devfs strawman > argument). True, lookups will still have to go through /dev, but the > dcache pretty much obviates that argument. (Also consider that opening > devices is generally in the noise as far as most applications are > concerned. It's hardly a common case that we need to optimize.)
The only issue is that you then lose /dev on filesystems which don't support UNIX nodes (ie devfs on ms-dos partitions). Though there are other ways of achieving the same effect, so it's no big loss.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
| |