Re: Heads Up: CAM ABI changes

:*grin*
:
:You're not about to go preach on an UNCOL as well are you? ;)
:
:>    That is, we need a generalized big-ticket solution and shouldn't worry
:>    about non-core ABI breakages a this stage.
:
:Does this involve versioned structures and such as well?
:
:-- 
:Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono

    I am thinking of having the kernel return a capability array that
    identifies various system structures:

	int count = getsysstructure("proc", cap_version, buf, sizeof(buf));

		Returns the number of capability elements for the structure
		or -1 if the buffer was not big enough (ENOSPC) or if the
		system structure could not be found (ENOENT).

		If buf is passed as NULL the number of capability elements
		required is returned or -1 if the structure could not be 
		found.

    This could be used by userland programs to identify the structure and
    copy the data to the userland structure equivalent.  And we could also 
    use this for our emulation layer to do the same thing (making it
    completely transparent).

    This allows us to be backwards compatible with 'old style' code which
    doesn't check.

    This also allows us to supply libc routines to translate structures
    given two capability arrays and two data buffers, which means we would
    also be able to supply libc routines that do all the necessary work for
    us.

    The capability structure would look something like:

	struct sys_capability {
		int32_t	cap_type;	/* type of entry */
		int32_t	cap_size;	/* size of target element or value */
		int32_t cap_offset;	/* offset of target element or -1 */
		int32_t cap_reserved;
	};

    Capability types:

	CAP_TYPE_NOP			0
	CAP_TYPE_CAP_STRUCTURE_SIZE	1
	CAP_TYPE_CAP_VERSION		2

	CAP_TYPE_INTEGER		(CAP_TYPEF_DATA|0x01)
	CAP_TYPE_UINTEGER		(CAP_TYPEF_DATA|0x02)
	CAP_TYPE_STRING_BUF		...
	CAP_TYPE_STRING_PTR		...
	...

	CAP_TYPEF_DATA			0x100

					-Matt
					Matthew Dillon 
					<[e-mail]>