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);
But there's more work to do:
- need for .val being variable lenght or a union of different types?
- extend existing enums or define new ones for MODULATION etc?
- how to do FE_GET_FRONTEND
- etc.
I'm sure we could have endless debates over the details ;-)
I hope many others will comment which approach they like better,
or which one they think will be ready for prime time sooner.
Personally I don't care either way. I spent a lot of time discussing
the "multiproto" API and I believe it could be ready soon with
a few minor tweaks. OTOH this tag/value approach seems to be
more flexible, but who knows how much work it'll take to complete.
Johannes
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
