[linux-dvb] Why I need to choose better Subject: headers [was: Re: Why (etc.)]

[barry bouwsma]

--- On Sat, 9/13/08, Paul Chubb <paulc at singlespoon.org.au> wrote:

> around 2.6.22. At some stage the functionality in videobuf_core.c was 
> replaced by video-buf-dvb.c. This meant that when you compile against 
> the 2.6.22 headers it works fine but still loads the videobuf_core 
> module from the previous module set. Once you get to 2.6.24 it still 
> loads videobuf_core, however now you get a lot of symbol issues when it 
> loads and ultimately the driver for the card didn't work. This was 

Ah, thanks.  I've seen this (in the list) often and ignored it
as a newbie error.  (I ignore most things anyway)

Now I'm trying to hack* around something comparable in a diff
which has strangely disappeared from my screen, but may be
videodev.c --> v4l2-dev.c  which probably will/has cause(d)
issues.

* `hack' should be translated as, looking at the diffs, wishing
I had had more sleep, even if it had meant missing all the doku on
Chairman Humph (for those in the know) that I should have instead
recorded for later viewing, and wondering if a `make-it-compile'
hack is enough...  Am I making sense?  Should I sleep?


> 2) The v4l-dvb tree has complex firmware loading logic in tuner-xc2028.c 
> 
> So either could be fixed, and I fixed the first. I could have fixed the 
> second by investing more time.

Just to be clear -- did you fix the firmware issue, or the issue
with migration of, and changes to, source files, which in my
hum^Wignorant opinion, would be the more difficult one in general?


>  But I don't think that is why people talk 
> about incompatibility between the two.

It's helpful to me, nonetheless.  I am sympathetic to the fork,
as my `production' (were I to produce anything; in reality, I
mean that it's been several years operating with only power
failures requiring attention, otherwise generally running with
full CPU load) machine is 2.6.14 and has loads of hacks which
I need to apply to a more recent kernel, should I find a stable
one (perhaps the hardware of my development machine is suspect
here, as I now have nearly a week uptime on the same kernel
which would typically freeze/panic within a few hours -- watch
it wedge solid before I can send this, again), and much of the
code which I've hacked (UFS large fragment size filesystem,
ISA ethernet and others) has or may have suffered substantial
rewriting since I got it working...  That second sentence was long...


thanks for your feedback!
barry bouwsma