Re: PROPOSAL: /proc/dev

Richard Gooch (rgooch@atnf.CSIRO.AU)
Thu, 1 Jan 1998 16:39:35 +1100

James Mastros writes:
> On Thu, 1 Jan 1998, Richard Gooch wrote:
>
> > H. Peter Anvin writes:
> > > > > These are the arguments the proponents shoot down constantly, but they
> > > > > never address any of the REAL (IMO) problems (although the kernel
> > > > > space usage is likely to be prohibitive if done anything remotely like
> > > > > correctly.) YOU REALLY DON'T WANT CALLBACKS -- if you do, then your
> > > > > device performance and reliability is going straight into the toilet.
> > > >
> [...]
> > Ah, I see. I'm proposing something that explicitely *does not* have a
> > user-space daemon. I personally find kernel code that relys on a
> > user-space daemon to complete it's work as ugly (though of course
> > there are some cases where you don't have a choice in order to avoid
> > kernel bloat).
> >
> > I'm proposing a small, kernel-space only scheme. Either /proc/dev, or
> > possibly devfs.
>
> I'm propasing a specificly middle-of-the-line scheme. Here is how it works.
>
> Creation of files is done like this: whatever function wants to create the
> file calls a function to create a file in /dev. That function checks if any
> code has registered itself to do that. If not, it just does excatly what
> the caller asked. If so, it calls that function (which can do whatever it
> wants to, including doing callbacks with a userspace daemon). That function
> then does the dirty work of creating the dentry and inode (which are setup
> to always be inuse untill removed... not that hard, just up the ref count a
> bit.) The d&icaches then do all all our work...
>
> Was that understandable? If not, please say so, I have a tendincy to babble.

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
- create a virtual file in /proc/dev on a procfs
- create a virtual file in /dev on a devfs
- create some virtual file which talks to a user-space daemon

right?

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.

Regards,

Richard....