This is the one I favour.
> > - 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 think you really want to unload the devfs module. If you want
an extension mechanism, fine, but not I suggest by replacing the devfs
module. Instead, ye custom module can register overrides with the
devfs driver/module.
> > 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)).
devfs_register ();
devfs_unregister ();
and such should be able to provide all the overloading you need.
So, my current thinking is:
Device driver startup code registers the device entry, giving the name
of the /dev entry, the permissions, ownership and so on as well as
major&minor numbers for legacy disc-based /dev systems. Another
parameter would be the name of the module to pass to kerneld when
someone open()s /dev/someentry. The ctime of these entries would be 0
(or perhaps system boot time).
A system script could be used to change permissions of /dev entries,
which is called by /etc/rc or whatever. This script uses a simple
database to determine which devices to fiddle.
Another system script is called when shutting down the system which
scans /dev for entries with a ctime newer than 0|boot-time. Any
modified entries will be written to the database mentioned above. The
point of this is that when the sysadmin manually changes
permissions/ownership from the shell, those settings will be preserved
across reboots. The beauty of this scheme is that it needs bugger-all
help from the kernel (read: no kernel bloat), and also doesn't require
the kernel to ask a user-space daemon about permission details.
A simple implementation of this will require one kernel-memory inode
per available device. Given that there are usually not many available
devices, this overhead should be minimal. If this were ever to become
a problem, we could look at ways of avoiding creating VFS inodes for
each device.
The question of symlinks: either the devfs supports creation of
symlinks (stored in RAM) or you require symlinks from an external
filesystem (not very nice). Once again, the system boot scripts can
generate the symlinks and the shutdown script can store any symlinks
in a database.
So, comments please. I'm trying to evolve the above into a
specification. Once all the necessary requirements are laid down,
implementation can start. Given that this topic is somewhat
controversial, I think the best way of sorting it out is to implement
a reasonable solution and let people play with it.
Regards,
Richard....