Re: incompatible unaligned.h between x86 and ppc - kernel-hackersverify please
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.
Reply to: