Hi,
I call this 'extended attributes' for lack of a better name. 

What I want to do is provide a generic method to add additional 
attributes to kernel-structures (proc structure, [vi]node, socket,
pcb ...).


Turn on those flames please :-))
    Stefan 

(I send this from my private address, but will respond mostly from
 my work email-address <grefen@hprc.tandem.com>)

BTW:
    I'm not good at writing this stuff in any language besides C and if the
    stuff below sometimes sounds like marketing babble, it's because I
    just finshed 'selling' a netbsd project to my managment.

-------------

Motivation: 
    Like Matt Thomas I need to add additional information to the proc 
    structure.  I also have to do it for file-descriptors in the near future.

Basic idea:
    An attribute is an opaque data-structure attached to kernel-structure.
    It has defined methods to handle events (internalize/externalize data 
    (fd to fp, pid to proc-pointer ...), to modify/change values, lookup).
    These methods are defined per attribute-class.

    External attribute-types are identified by class-name and an 32 bit id.
    Internal attribute-types are identified by a kernel-structure-type 
    depended index.

    Any number of attributes can be attached to a kernel-structure, but only
    one pointer slot is needed there. It will point to a 'directory' for
    this structure where the attributes are located in fixed slots, assigned
    at attribute-class registration time.

    Kernel-Structure depended inheritance rules are available and
    automaticly handled, unless the attribute defines its own rules.
    (eg. a process passes a reference to child-processes, a directory
     to newly created files ...)

    Attribute handling goes through new syscalls.

What for ?????
    There are certain extensions that need to store additional information
    in kernel-structures. This just defines who this is stored, so that
    an extension just needs to supply its own attribute functions, without
    recompilation of the whole kernel. This extension can even be an lkm.
    The internalize/externalize methods also allow stuff like the file-system
    to store the attributes permanently on disk.

    Some application ideas:
	File-system (inode/vnode)
	    ACL's
	    DMAPI
	    'Compartments (like in UNICOS)'
	    fine-grained credentials
	    Device defaults ...
	    ...
	Process
	    fine-grained credentials
	    'Compartments (like in UNICOS)'
	    accounting/audit 
	    Emulation information could be stored here.
	    All the special hooks in fork/exec can be moved.
	    ...
	pcb
	    'Compartments (like in UNICOS)'
	    ...

This is a generic version for "struct proc_extension" as proposed
by Matt Thomas in mail to tech-kern (Date: Mon, 16 Mar 1998 10:01:43 -0500)
    <Message-Id: <199803161503.KAA06967@tecumseh.altavista-software.com>

In Matt Thomas scheme you've always to walk the the list to find a specific
attribute, (and there is now way I know off, to identify the attribute).


Why this approach ??
    There are two requirements that need to be fulfilled:
	Persistence of the attribute information across OS-releases
	    and machines --> We can't store a magic pointer somewhere, thats
	    why attribute classes got names. 
	Fast access from the kernel as it may be often referenced in common
	    operations and only one pointer in kernel-structure. --> No name 
		lookup. Only one pointer mandates an index table or a hash.

What needs to be done in the source tree ?
    Depends on subsystem involved.
    For processes:
	Fork/exec handler which creates the new attribute directory
	and deletes/reference/dups attributes 
	addition to sysctl code et. al. to modify information
	    based on stored attributes (access control etc.)

    For file-systems:
	persistent storage of attributes
	    can be on vfs layer (hidden attribute file) or directly per
	    inode 
	    the per inode approach has the benefit that part of the information
	    is available with out further disk-access, the disadvantage is
	    that this has to be done for every file-system that should support
	    these attributes.

    For pcb's:
	inheritance of attributes from interface structure and 
	listener sockets.

    These are all generic changes, which do nothing if attributes are
    used and enable people to plug-in any number of enhancements (even
    by loading a lkm) without any kernel changes.

    The also can be easily ifdef'ed EATTRIBUTES and the pointer to the
    attribute index table will be just a placeholder to avoid structure
    size changes.
--
Stefan Grefen                           Am Hummertal 4, 55283 Nierstein, Germany
grefen@carpe.net                        +49 6133 927484   Fax:+49 6133 927486
    The road to hell is paved with good intentions.  And littered with
    sloppy analysis!