eeh@netbsd.org writes:

	> 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:

	Sounds a lot like linux procfs

No, not really.

	[...]

	>    int setprop(kdatabase_t db, opaque_t object, const char *name, 
	> 		void *val, size_t len, int type, int wait);
	>    size_t getprop(kdatabase_t db, opaque_t object, prop_iter_t *next,
	> 		const char *name, void *val, size_t len, int *type);
	>    int delprop(kdatabase_t db, opaque_t object, const char *name);
	>    int copyprops(kdatabase_t db, opaque_t source, opaque_t dest, 
	> 			int wait);
	> 

	O dear. So many new syscalls, so many new tools needed to play with
	them :-(

	Why not recycle those good old tried and tested favorites, like read(2)
	and write(2)? Then all your users need is a working shell.

These are not really supposed to be manipulated from userland.
The primary purpose of this is for communication between various
parts of the kernel, hence the interface are designed for efficient
use inside the kernel.  Userland access is of secondary, or even
tertiary importance.

For the most part, the data stored in properties is in a binary
format, so you need to process it to make it human-readable.  So
read(2) and write(2) from your shell or text processing utilities
would not work very well on the data.

The system calls are there primarily for debug purposes.  I would
prefer to use sysctl() for this purpose, but it is not really
suited to accessing dynamically changing data like this.

	[...]

	> Similar interfaces are provided for manipulating kernel databases
	> for both inside the kernel as well as a system call interface.  Only
	> root can create or modify property values, but anyone can query
	> properties.

	A bit arbitrary. If you had an fs for it you'd get finer grained
	permission control for free. . .

Not really.  Since the data is created dynamically, permissions would
not persist.  And even running a script at boot time to set the permissions
would not be much help.  Everything would need root permissions.  Also,
since this is primarily designed for communication between different
modules in the kernel, permissions are just so much extra overhead.

	Note that I'm not saying you should simply copy linux procfs, because
	that interface is very very messy both inside and outside the
	kernel. You could keep your interface but implement it on top of a
	filesystem, which would simplify the userspace interface like
	anything and make it much more powerful.

A filesystem does have some advantages in this case.  But a filesystem
must be mounted to be useful.  Not to mention the fact that the property
heirarchy does not really lend itself to a filesystem tree layout.  
And different databases would want to be mapped to different structures.
A device database would want to be tree-structured, by device node.
A routing database would want to be a big table.  The generic properties
infrastructure has no knowledge of the structure of the underlying 
data layout.  

Now, one thing I had considered is to make create a device node and
use ioctl(2)s to access the database, much like openprom handling
is done.  The problem with this scheme is that you really would want
one device node for each separate database, and since databases can
be created dynamically, this would quickly become difficult to 
maintain in a consistent manner.

Eduardo