[linux-dvb] DVB-S2 API vs. HVR4000: When?

Steven Toth stoth at linuxtv.org
Mon Nov 5 18:20:04 CET 2007


Markus Rechberger wrote:
> On 11/5/07, Steven Toth <stoth at linuxtv.org> 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




More information about the linux-dvb mailing list