Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)

[hermann pitton <hermann-pitton@arcor.de>]

Hi,

Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab:
> Andreas Oberritter wrote:
> > Andy Walls wrote:
> 
> >>> As Honza noted, these ioctls are used by enigma2 and, in general, by
> >>> software running on Dream Multimedia set top boxes.
> >> Right, so reverting the patch is not an option.
> >>
> >> It also makes implementing multiple dvr0.n nodes for a demux0 device
> >> node probably a waste of time at this point.
> > 
> > I think so, too. But I guess it's always worth discussing alternatives.
> 
> If this discussion happened before 2.6.32 release, and provided that a different
> implementation were agreed, things would be easier, as a different solution like
> your proposal could be decided and used.
> 
> Now, we have already a regression on a stable kernel, and solving it by
> creating another regression is not something smart to do.
> 
> >From what I understood, the regression appeared on an old, orphan
> application with a non-official patch applied on it. Other applications with
> similar features weren't affected. On the other hand, if the patch got reverted, 
> we'll break a maintained application that is used on a great number of devices,
> and whose features depend on the new ioctls.
> 
> We are too late in -rc cycle, so probably there's not enough time for
> writing, test, validate any new API in time for 2.6.33 and write some compat
> layer to emulate those two ioctls with a different implementation.
> 
> So, removing those two ioctls is not an option anymore.
> 
> 
> Cheers,
> Mauro

during the still ongoing v4l to v4l2 conversion, all major apps did ship
with their own headers.

Since we keep backward compat, that previously unknown to me
alevt-dvb-t, agreed it is a nice to have, should compile against the
older headers instead latest kernel headers, until someone maintains it
again and takes advantage of later improvements.

Untested, but usually we see just such.

Cheers,
Hermann