Messages in this thread | | | Date | Thu, 1 Jan 1998 01:15:08 -0500 (EST) | From | James Mastros <> | Subject | Re: PROPOSAL: /proc/dev |
| |
On Thu, 1 Jan 1998, Richard Gooch wrote: > > I think I got that. What you're suggesting is an interface which > allows you to plug in any of the following implementations: > > - create a real file in /dev on an ext2fs Well... yeha... but any of these schemes can do that...
> - create a virtual file in /proc/dev on a procfs Not really. I want a nice, clean /dev devfs.
> - create a virtual file in /dev on a devfs Yeha.
> - create some virtual file which talks to a user-space daemon NO! Have a /dev devfs that talks to a user-space daemon. Should you for some odd reason want one. But, more importantly, have a runtime, user, replacable policy. I'm thinking of having a kernel module do this job instead of a userspace daemon.
One problem with this approach that I just though of: We want the useage count (of the module) to be zero, so the user can remove it at will. But then again, we don't want kerneld to unload it accedently... any ideas?
> I don't see a problem with such an interface. What I don't see is why > you would want a user-space daemon at all. I think (hope) that a > simple implementation can be developed without any need for a daemon, > yet still retaining necessary functionality. So do I. But we should have a replacable way of doing this, and it should cost only a jnz, and a jmp. (Is overide_create != NULL? Then call that function with the same arguments we got (same arguments == no need to pass them again, our caller already did all the work)).
> Regards, > Richard....
-=- James Mastros -- Information as a base of power is coming to an end. In the way the world works tomorrow, the power to *do* *something* *with* *information* is what will matter.
-=- James Mastros, rephrasing Nugget (David McNett, distributed.net Big Man)
| |