Le Tuesday 14 October 2008 16:57:42 Steven Toth, vous avez écrit :
> Andreas Oberritter wrote:
> > Hello Steve,
> >
> > Steven Toth wrote:
> >> I'm mutating the subject thread, and cc'ing the public mailing list into
> >> this conversion. Now is the time to announce the intension to merge
> >> multi-frontend patches, and show that we have tested and are satisfied
> >> with it's reliability across many trees.
> >>
> >> (For those of you not familiar with the patch set, it adds
> >> 'multiple-frontends to a single transport bus' support for the HVR3000
> >> and HVR4000, and potentially another 7134 based design (the 6 way medion
> >> board?).
> >
> > is this code still using more than one demux device per transport bus, or
> > has it already been changed to make use of the DMX_SET_SOURCE command?
>
> Yes.
>
> I'm glad you mentioned this, I discussed this at LPC with a number of
> people.
>
> The current code that's being tested in the mfe tree's implements
> multiple demux devices, that has not changed.
>
> Speaking with two other devs at LPC we discussed changing this approach
> (and the current approach for many dual channel boards), to having a
> unified single adapter device, with either multiple demux devices or
> not. As a basic discussion topic the ideal had a lot of support.
>
> A good example of this in the current kernel (without any MFE patches)
> is the current cx23885 driver, that registers adapter0 and adapter1 with
> two different ATSC frontends. I question (and argue) that it should
> really be /dev/dvb/adapter0/demux{0,1}
Yes, sounded logical to me also. The fact that "frontend" and "demux" was
suffixed with an integer suggested that, that's why kaffeine probes
frontend/demux >0.
I think that the actual way of populating multiple adpaters is to make these
devices working with current apps without any modifications.
On the other hand, since only dreambox drivers seem to use multiple frontends
on single adapter, maybe this actual (and bad, i agree) way should be kept
and multiple frontends on single adapter reserved for exclusive frontends
until the api provide such properties query, so applications can assume these
frontends to be exclusive.
> The same is also true for the for the multi-frontend patches, it should
> probably change (as part of an overall adapterX overhaul) to match the
> LinuxTV DVB API and register only one demux device.
>
> That's a much larger project, and has not been addressed yet. Many users
> will probably also argue that it's unimportant work, when application
> are currently working.
>
> My opinion is that we would review the adapter usage and determine
> whether we need or want to change that. If we do change it we should
> probably add some better application interfaces from the adapter inode -
> In a model similar to the S2API has done for frontends. Applications
> would then be able to query board specific details in a way that cannot
> be easily done now.
>
> However, regardless of my opinions, it would be a mistake to hold back a
> merge of the current multi-frontend patches. Instead, we should merge
> the large number of MFE patches and start a larger adapter level
> discussion and slowly evolve with smaller patches. (We'll need someone
> to draft an RFC).
>
> Are you volunteering to address this larger subject?
>
> - Steve
--
Christophe Thommeret
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
