Hi Johannes,
Johannes Stezenbach writes:
> On Wed, Aug 31, 2005 hunold@xxxxxxxxxxx wrote:
>> enum dvb_demux_pid_filter_packet_selection {
>> DVB_DEMUX_TS_PACKET = (1 << 0), /*!< default: process the
>> whole TS packet */
>> DVB_DEMUX_PAYLOAD_ONLY = (1 << 1), /*!< only deliver the payload
>> (ie. strip off the TS header) */
>> DVB_DEMUX_ADAPTATION_ONLY = (1 << 2), /*!< only deliver the TS
>> header and any adaptation fields if present */
>> };
> If these enums aren't flags, then why the hell do you make them
> look like flags?
I don't want to make them look like flags. Flags can only be used for saying
on/off. This is not true for the stuff above, they are selections.
For example, if packet selection is done with flags, you can specify
combinations like DVB_DEMUX_PAYLOAD_ONLY | DVB_DEMUX_ADAPTATION_ONLY like in
V3. This technically does not make sense and looks stupid.
Putting this into a selection is more natural, because you cannot do stupid
combinations any more.
Putting flags and selections into a separate structure like struct
dvb_demux_pid_filter_prop makes it even more clearer I think.
> I believe one PRIO cap should be enough
What about putting *all* capabilities into a separate struct that can be
queried at once instead of a lot small capabilities that need to be queried
individually?
> Johannes
CU
Michael.
