Markus Rechberger wrote:
> On 11/5/07, Steven Toth <[EMAIL PROTECTED]> wrote:
>> Johannes Stezenbach wrote:
>>> On Fri, Nov 02, 2007, Steven Toth wrote:
>>>> The design goals for me are:
>>>>
>>>> 1) We stop trying to predict what the API will need in 5 years, and focus
>>>> on building a very simplistic ioctl API for getting and setting generic
>>>> frontend properties, it should be basic enough to deal with any new
>>>> modulation type (or advanced tuner) that we know of today.
>>> good one
>>>
>>>> 2) We change the tuning mechanism from being (mostly) atomic
>> (SET_FRONTEND)
>>>> to a looser command/sequence definition. (Thereby stepping away from
>> fixed
>>>> structs that define the ABI). With two new ioctls
>>>> (get_property/set_property) and a simple property struct which specifies
>>>> how generic types are passed to/from the kernel.
>>> no so good
>>>
>>>> 3) A userland library _may_ offer a number of helper functions to
>> simplify
>>>> in terms of applications development, turning this:
>>> many people seem to hate ALSA, there's a lesson to be learned here
>>>
>>>> command.id = BEGIN_TRANSACTION
>>>> ioctl(SET_PROPERTY, &command);
>>>>
>>>> command.id = SET_MODULATION
>>>> command.arg = 8VSB
>>>> ioctl(SET_PROPERTY, &command);
>>>>
>>>> command.id = SET_FREQUENCY
>>>> command.arg = 591250000
>>>> ioctl(SET_PROPERTY, &command);
>>>>
>>>> command.id = VALIDATE_TRANSACTION
>>>> ioctl(SET_PROPERTY, &command);
>>>>
>>>> command.id = END_TRANSACTION
>>>> ioctl(SET_PROPERTY, &command);
>>>>
>>>> Into a more human readable form like this:
>>>>
>>>> int tune_8vsb(frequency);
>>>>
>>>> It's a basic approach, we trade off multiple ioctls (at a very low rate)
>>>> entering the kernel, for a very flexible tuning approach to frontend
>>>> control.
>>> Once you have those tag/value pairs, you could batch them
>>> together in an array and pass them down in one ioctl. This
>>> avoids the ugly transaction stuff and keeps it atomic.
>>> And I think it wouldn't look too ugly in user code, e.g.:
>>>
>>> struct dvb_tuning_param p[3] = {
>>> { .id = MODULATION, .val = MOD_8VSB },
>>> { .id = FREQUENCY, .val = 591250000 },
>>> { .id = 0 }
>>> };
>>> ioctl(fd, DVB_TUNE, p);
>>
>> You can't reliably pass in variably length arrays into the kernel, or
>> none of the other kernel wide drivers do, they need to be fixed length
>> for sanity reasons. That being said, I have a newly defined type which
>> represents an array enabling 16 messages to be passed in a single
>> transaction.
>>
>
> Hi Steven,
>
> just have a look at the i2c-dev driver it passes a variable length to
> the kernel.
>
Hey Markus,
Good. I looked at about 40 different drivers, then ran some kernel wide
greps before giving up. I can see it now, this is a much nicer approach.
Thanks,
- Steve
_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
