Anyone who looked at the first one, would see that it suffered from context
switches due to the fact that a large percentage of the system was maintained
in user space by a daemon.
While the daemon is essentially a necessary part (The kernel knows nothing
about users or local system configuration), I planning on reducing its
workload. The current setup uses a communication link to pipe all the
information (kernel<-->daemon). This of course suffers from context switches.
What I'm intending to do, is have the daemon handle the changes to a
filesystem, by allocating a memory map (probably shared IPC) whose address
would be passed to the kernel. The map would effectively list file
information (like uid,gid,name, mode), allowing the kernel to access the list
and provide the necessary inode/dentry information.
The daemon would only need to change the map if some major configuration
change occurs like a new set of modules were installed. The map would be
created at boot up, after it is informed about the necessary kernel driver
information and module information has been gathered.
The drivers could define kernel-resident or userspace devnames. The built-in
kernel driver's resident symbols would exist as dentries all the time, and
userspace devnames would be put in the existing communication channel for
the daemon to handle, when it starts up.
Modules could define devnames in their modinfo section, allowing the daemon
the ability to extract them without loading the module.
mode and ownerships of kernel-resident symbols could be changed by the daemon
using chmod/chown etc.
Modules could define devnames in their modinfo section, allowing the daemon
the ability to extract them without loading the module.
The daemon would also maintain other information that would not be contained
within the shared map. for instance the devname <--> module mapping.
The kernel would need to perform lookups mainly, however it would be quite
easy to allow for updating for some existing elements, like uid on tty...
names.
Theres a few more considerations I'm planning on, however I'm no experienced
kernel hacker (yet!!), so if there are any comments.
cya
karl