[sorry, I accidentally hit 'send' too early before completing this mail] On Freitag, 28. März 2008, you wrote: > On Fri, Mar 28, 2008 at 1:42 PM, Stefan Lippers-Hollmann <[EMAIL PROTECTED]> > wrote: > > If you look at the history of this bug, it had be reassigned to linux-2.6 > > in august 2007 (and re- reassigned to lirc ~2 weeks later after talking > > to linux-2.6 maintainers). > > Ah yes, I should have seen that. It looks like Julien believed that > the problem was a _userspace_ application including bttv.h, not a > kernel module depending on a header that isn't part of linux-headers > for some reason. If the lirc userspace tools want to compile against > bttv.h from the kernel, that's a separate issue with a separate > solution. > I still have the feeling that I'm missing something -- it seems like > including a header in linux-headers, if there are Debian-packaged > kernel modules that need it in order to build, is such a no-brainer > that I must be misunderstanding what's going on :-/. That's true even > if the headers are not part of any legitimately exported kernel API. > I mean, the whole "breaking Linux headers out into a separate > package so that kernel modules can compile against it even if they > _think_ they need to compile against a previously-built kernel source > tree" idea is a Debian-specific construct, with nothing to do with the > upstream kernel, right? I just don't see any sense in which bttv.h > should be considered "private" and not provided to a kernel module > that wants to compile against it. > Again, I must be missing something.
The decision which headers get shipped in linux-headers-$KVER is basically made upstream by the mainline kernel developers, who are investing a lot of time to clean up the userspace (and kernel) visible API. cf. http://svn.debian.org/viewsvn/kernel/dists/trunk/linux-2.6/debian/rules.real?rev=10983&view=markup in the install-headers_$(ARCH)_$(FEATURESET)_$(FLAVOUR) target. > > In the end this bug is totally unimportant as long as #471383 remains > > unfixed, which prevents lirc_gpio from compiling at all with recent > > kernels (2.6.23, 2.6.24). > > I agree with all of this and what follows completely -- it sounds > like not compiling lirc_gpio at all might be a good way to kill two > birds with one stone :-). If upstream isn't keeping it working with > modern kernels, then I don't see much reason for it to hang around > causing problems for the other modules in the Debian package. > Cheers. This is definately not a preferred "solution", but may be a potential result unless a fix can be found. Truth to be told, the required changes are not simple and will have a larger impact on the modules' internal design structure. Right now I am not sure (or confident) to fix this particular bug soon, but will keep an eye on upstream development/ mailing lists and give the lirc_gpio some more in depths review as soon as the important bugs affecting all drivers and functionality as a whole [1] are fixed. lirc just is basically a conglomeration package attempting to cover a whole input subsystem with quite different devices, some of them requiring kernel modules, some of them handled purely in userspace - some actively maintained with large numbers of users, some barely maintained at all. This doesn't mean lirc_gpio is about to be forgotten, but this issue goes beyond a 'simple' compile fix for a slightly changing kernel API (the symbols as a whole have been removed upstream in mainline kernel) and is close to rewriting the module from scratch (yes, this is an exaggeration, but not too far off), which is ideally handled by someone who actually has access to this particular hardware and can debug the issue. Regards Stefan Lippers-Hollmann [1] in not particular order #450521, #393575, #433607, #456325, #369076
signature.asc
Description: This is a digitally signed message part.
