eeh@netbsd org wrote:

> -----Original Message-----
>
> It has come to my attention that there is a desire to use properties for
> objects other than devices.  To address this need, here is a proposal
> for a framework to support generic kernel properties.  More specific
> property frameworks, like device properties, can be built on top of
> this:
>
> Eduardo
>

Hi,

I am currently working on a maybe similar, but, compared to your proposal,
simple system. It is a small, memory based filesystem, which has to be
mounted like other file systems. Each configuration parameter is represented
by a single file. Ordinary shell commands can be used to inspect or alter
the configuration. A distinction is made between parameters defined by user
space processes and kernel space modules.

A kernel module puts the names of its configuration parameters into the
configuration file system, but retains control about the parameters values.
Read and write requests are forwarded to the controlling module, which
manages the memory containing the parameters value. If a parameter is
defined by multiple modules, each module manages its private copy of the
parameter, the file system forwards write requests to each defining module
and a read request to only one. No module is allowed to alter its private
copy of a registered parameter without using the file system. To change a
value a module calls the file system write function and the new value is
forwarded to all other modules automatically. (this scheme seems to be more
simple than a callback based)

A user space process inserts a configuration parameter by creating a new
file in the configuration file system. The values of such parameters are
controlled by the file system, which mallocs the memory needed. User space
processes must use select() to get update notifications.

We chose this scheme, because we can use simple shell commands to manipulate
the configuration. A complete configuration tree can be saved with tar.
Since the parameters are untyped (thus not human-readable), this is not a
user-friendly system, but our main purpose is to configure an embedded
system, thus no customer should get in touch with the plain configuration
elements.

To allow customers to manipulate configuration parameters, a daemon must be
implemented. Its purpose is to hide the configuration details and translate
the untyped byte stream into a human-readable representation and vice versa.
It may export this functions via http. Developers use hexdump and other
shell commands to manipulate configuration elements.

Tobias