I like this proposal.  A lot.

Actually, it almost precisely mirrors a similar API I created for using
nvlists in Solaris with cryptographic accelerators (where we had
"capabilities", and a bunch of arguments which varied depending upon the
crypto alg used.)

    -- Garrett

Jason Thorpe wrote:
>
> On Jun 6, 2006, at 10:29 AM, Garrett D'Amore wrote:
>
>> That's not a bad idea.  Is there an example for passing properties in
>> ioctls, or is there another way to exchange this data?
>
> proplib is new enough that it's not being used for this purpose yet. 
> However, it's perfect for the "capabilities supported" / "options
> enabled" kind of thing, where the list might grow in the future
> (beyond 32-bits worth of features, perhaps).
>
> As for how to pass it back and forth, prop_dictionary_externalize()
> before sending it across the boundary, prop_dictionary_internalize()
> when receiving it from across the boundary.  Maybe we should even make
> a generic ioctl argument:
>
> struct plistref {
>     const char *plist_ptr;
>     size_t plist_len;
> };
>
> Then your hypothetical "get capabilities" ioctl could be:
>
> #define    FOOGETCAPS    _IOWR('f', 0, struct plistref)
>
> and your "get properties" / "set properties" could be:
>
> #define    FOOSETPROPS    _IOW('f', 1, struct plistref)
> #define    FOOGETPROPS    _IOWR('f', 2, struct plistref)
>
> We could probably even have a generic helper function in the kernel,
> and a corresponding one in userspace, that took care of the temporary
> buffer allocation, etc.
>
>
> -- thorpej


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191