On Mon, Mar 03, 2008 at 04:03:09PM +0400, Manu Abraham wrote:
> >- make SET_PARAMS the call to honor delivery in dvbfe_params and remove
> > the setting of the delivery of GET_INFO
> >
> >I'd prefere the 2nd option because currently the usage and naming
> >is an incoherent mess which should better not get more adopters ..
>
> Your 2nd option won't work at all. It is completely broken when you have
> to query statistics, before a SET_PARAMS.
I have no problem with beeing able to query stats - I have a problem
that a GET call changes in kernel state, and the SET calls options get
ignored where it should be the other way round.
Probably you can tell me the reason the delivery option in the
dvbfe_params gets ignored on a DVBFE_SET_PARAMS ? I dont see the
rational behind this... The option is there - correctly filled and
gets ignored or better overriden by previous ioctls - Every other
parameter for the delivery mode is in that struct.
Please tell me why the GET_INFO delsys/delivery option gets set as the next
to use delivery mode. Even if i want to have stats just dont fill them
when the delsys does not match the currently set delsys as that would
be the right thing - Querying DVB-S2 stats when tuned to DVB-S should
return nothing as there are no stats - but setting the delsys to DVB-S
is BROKEN as i asked for stats not to change the delsys.
> Additionally, this was quite discussed in a long discussion a while
> back. You might like to read through those as well.
I did partially of it ... and i found the same corners of this API to be
broken by design.
> Maybe DVBFE_GET_INFO can probably be renamed to DVBFE_INFO if it really
> itches so much.
No - its much more fundamental problem ... Options belonging
together are passed in seperate ioctls in non obvious (read: strange)
ways into the kernel (delivery system via GET_INFO and delivery options
via SET_PARAMS).
Options which are together in the same struct are not used together e.g.
delivery mode and parameters are in the same struct which get passed by
an ioctl but get partially ignored or better overridden by previous
ioctls in non obvious ways...
As i said - incoherent mess from the user api ...
Flo
--
Florian Lohoff flo@xxxxxxxxxx +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
