On Wed, 2004-11-03 at 17:39, Benjamin Herrenschmidt wrote: > On Wed, 2004-11-03 at 23:37 +0100, Klaus Schmidinger wrote: > > > It's a bug in VDR to use a platform independent way of accessing unaligned > > data? I don't think so... > > It is a bug in _ANY_ userland application to rely on an inline function > exposed by a kernel header.
He's using a glibc header, unless "-I" is involved. Anything under /usr/include is NOT a kernel header, despite any kernel origin. > If glibc doesn't provide an equivalent (and > maybe it does), then you'll have to find a different way. Sorry, I know > it sucks for your problem, but as I wrote, there is absolutely no > guarantee that the kernel implementation of this is actually inline, or > doesn't rely on kernel internal thingies, etc... Sure. In that case, glibc must provide an implementation. Since the header in question comes from the glibc-headers package, the primary responsibility for providing this API belongs with glibc... but of course, the sensible thing to do is patch the kernel so that there is less work to do. > In general, the only ABI exposed by the kernel is syscall interface. > It's been comon practice every now and then to abuse the kernel headers, > but that's what it is... an abuse. Yes and no. Raw kernel headers were a legitimate part of the libc 5 API. It has been expedient to use lightly-modified headers to generate the glibc-headers package. When parts of the API are made unavailable via this mechanism, glibc must be modified to take up the slack. The glibc-headers developers should have been warned about the kernel change. Since they weren't, and didn't catch it, there is a problem. While primary responsibility remains with glibc, the productive thing for now would be to remove the useless #ifdef from the kernel. After all, if userspace isn't supposed to be using kernel headers, all the #ifdef __KERNEL__ stuff can be deleted from the kernel source. It's totally pointless, isn't it? It serves no purpose UNLESS it is accepted that userspace will more-or-less be using kernel headers. > If glibc wants to chip modified version of the headers that do expose > those functions, then fine. In that case, it becomes glibc's > responsibility to provide this interface to you. But not the kernel. Sure. The end user doesn't care if the glibc-headers package removes the #ifdef or if the #ifdef is removed in the kernel, as long as /usr/include ends up with the API in the end.
