> > > And I think it would be wrong to delay DVB-S2 support until you > > > have all of DVB-H, DVB-T2, etc. properly hammered out. I have to agree with Johannes. The current 2.6 development model is based on "Commit earlier and commit often", as stated by Linus. This means that a big trouble can (and should) be split into smaller troubles and cleaner solutions. This also means that the life cycle for adding newer functionalities in kernel shouldn't take a large amount of time. If we wait for finishing V4 API to support DVB-S2, some drivers, already written, should wait, losing their time to market (In fact, they are already late). I don't see any reason for postponing it more. On the other hand, userspace API should be forever. So, changes should be done in a way to avoid breaking binary compatibility with userspace apps. So, an extra care should be taken to avoid creating APIs that may need to be changed in a near future. One possible way to try to solve this dilema is to mark the newer API changes as EXPERIMENTAL, for quite a few kernel versions. Anyway, IMO, we should prioritize DVB-S2 and multiple frontend support (for hybrid DVB-T/DVB-C boards). This doesn't mean that we should forget the other targets. For example, I'm interested on ARIB extensions, since we should be working soon on an ISDB-T board for Brazil's market. Cheers, Mauro. _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
