Subject: Re: qtopia
To: Christos Zoulas <christos@astron.com>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-kern
Date: 06/06/2006 13:14:30
Christos Zoulas wrote:
> In article <2C639E24-25C7-4083-B000-973CC36DD05C@shagadelic.org>,
> Jason Thorpe <thorpej@shagadelic.org> 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.
>>
>>
>
> shouldn't the pointer be const void *?
>
I wouldn't think so. As a "packed" property list, it really is a
character array. Making it void * would just mean having to add casting
later to do the pointer arithmetic necessary to unpack it.
-- Garrett
> christos
>
--
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