Subject: Re: qtopia
To: Jason Thorpe <>
From: Garrett D'Amore <>
List: tech-kern
Date: 06/06/2006 11:40:45
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
Phone: 951 325-2134  Fax: 951 325-2191