> 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.
-=- 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)