Michael Krufky wrote: > Klaus Schmidinger wrote: > >> Philip Prindeville wrote: >> >>> ... >>> Without wishing to polemic... am I the only person that wishes that >>> DVB development wasn't tied to having a bleeding-edge kernel? >>> >>> Given that the kernel *is* modular, why shouldn't the latest >>> module sources for DVB build against a 2.6.12 kernel? >>> >>> Is that not a reasonable expectation? >>> >>> Seems we'd have a broader base of testers to pool with... >>> >>> -Philip >> >> >> >> This is what has kept me from switching to dvb-kernel for >> quite a while. Whenever I had installed a new version of Linux >> on my VDR, the latest, greatest DVB driver required an even >> newer kernel :-( >> >> I wonder when they will require a kernel from the future... -) > > > I agree with the both of you completely, although it is difficult to > implement backwards compatibility from now looking backwards. This > type of thing is much easier to implement AS breakages occur, rather > than AFTERwards. > > Another roadblock is that the rules of dvb-kernel cvs indicate that we > should not use #IFDEF's, at least not for this purpose ... > > #IFDEF's are the easiest way to keep backwards compatability, but they > create a huge mess of the code... I don't blame Johannes for wanting > none of it, as it could create a maintenance nightmare. > > On the other hand, I have created a compat.h (located inside the > build-2.6 directory) ... Currently the only function this file serves > is maintaining compatability with some changes that we made to the > bttv code in v4l-kernel cvs. > > Not only must dvb-kernel stay compatable with the latest dev kernel, > it also must retain compatability with v4l-kernel cvs. I have made it > a point to maintain these inter-tree dependencies myself, and this is > why compat.h exists. > > For users of "hybrid" devices, that rely on code from both v4l-kernel > and dvb-kernel cvs, you can use the "make merge-trees" command from > within v4l-kernel cvs, and it will import the applicable frontend > modules from dvb-kernel cvs into v4l-kernel cvs. So far, this has > been working quite well, and v4l-kernel cvs *is* backwards compatable > with older kernels, although the tree-merge will only work against > kernels 2.6.12 and later. > > SO, back to the original point. Backwards compatability for older > kernels... We have compat.h to play with. Take a look at how compat.h > works inside v4l-kernel cvs. Some of the magic there can also be used > here. If anyone can find a way to increase compatability throught the > use of compat.h, feel free to send in patches. Of course, compat.h > can and is FULL of #IFDEF's ... and this is fine. > > This is a very difficult task, and it will be even more difficult to > find the time to get things like this done, but it isn't impossible, > at least I dont think so. > > Please keep in mind... Johannes has requested that any compat.h magic > shall be handled in separate commits from normal patches. This > simplifies the upstream patching process, and allows for the compat.h > changes to be prevented from upstream merging. > > With that said, now you know that an effort is being made for such > compatibility, although this effort is a passive one. Patches are > welcome, but I cannot guaruntee inclusion of backwards compatibility > patches..... Current development is the real reason why cvs is here... > Backwards compatability is nice for user testing, but I must say, it > ain't easy. > > Regards, > > Michael Krufky Hmmm... I personally have little use for the video functionality that a lot of DVB cards come with... I use them as tuners only, and see the analogue video capture capability (from a PAL/NTSC IF source) as unnecessary cruft... Probably because the chip already includes it, so the board manufacturers said, "well, for $.35 in extra popcorn logic and connectors, it's hardly worth not doing." Who actually uses the video capture logic? I've always wondered... On a multi-function card, does the driver have to handle all aspects of that functionality? Or can you have separate, stand-alone drivers that each handle one type of functionality, without them having to be aware of each other or interact with each other? I.e. can tuning and video capture and video playback (for full-feature cards with MPEG/AVC decompression) be handled by three independent subsystems and drivers? -Philip
