>> 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.
>
>Just so I can understand: what is the benefit of a systemfs if you
>already have a devfs?
>
Hi Richard. systemfs was intended to offload some of the system information
into userspace. The one on my web site is of course very primitive, and
suffered from context switches.
While one of its goals was a devfs which you have done an implementation of
(I should actually look at your code really), it also enables the ability to
put data into user land. for instance the PCI strings.
After thinking about it, I should actually separate /proc /dev /system into
different filesystems. I haven't looked at the process issues yet for /proc,
but /dev (tree of devices) and /system (used for run-time switches/system
information retrieval) will communicate with the user space daemon when it
is running.
As for your implementation, I must admit to not looking into it a great deal,
but I think there is just too much on the kernel side. Although there are
reasonable grounds to have one of some sort.
As for a device name format, I will be happy with whatever identifies the
device. The one thing that should exists is the ability for symlinks, and
to be quite honest its a driver issue not a devfs issue. However potentially
handling a large number of entries is a devfs issue.
cya
karl
(I finally got hold of a 2.1 tree (79) and can start doing mod's)