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
<dillon@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 5 之 5 篇)：