Bug 463342

That's a kernel header. You shouldn't be including it in userspace.

Those few kernel headers which _are_ available for low-level system tools and libraries to use are provided by the kernel-headers package.

<asm/unaligned.h> is not one of them.

Yes, technically it is a kernel header.

However, what that files provides is macros/functions for accessing unaligned data, which is something that user-space programs need to do.  Furthermore, there is nothing that requires kernel privileges for that operation.

No. That file provides nothing for you. You have no business including kernel headers.

It's not as if unaligned access is particularly hard to do without abusing stuff you shouldn't be looking at:

#define get_unaligned(ptr)                      \
({                                              \
        struct __attribute__((packed)) {        \
                typeof(*(ptr)) __v;             \
        } *__p = (void *) (ptr);                \
        __p->__v;                               \
})

Hm - Guess I disagree with that statement.  Kernel headers are headers that either:

1) Define prototypes for O/S internal functions that cannot be called from user-land
-or-
2) Define functions that use machine instructions that cannot be executed at user-land privilege levels

unaligned access falls into neither of these categories.

Any user-land application that needs to deal with unaligned access most certainly does have business using these headers, which is why they were in /usr/include/asm up until RHEL 5.

In terms of your macro, first, you mis-typed it (it won't compile as you typed it as one gets an illegal cast from void* to <annonymous struct>.  Secondly, that is the macro that is in the unaligned.h file on Itanium - so clearly that macro, and the unaligned.h file are *not* kernel files.  They are perfectly usable in user-land code.

The point of using a glibc supplied header is to ensure portability and performance when porting from one architecture to another.  Using the glibc-supplied header means that if there is a more efficient construct for performing unaligned access on a particular architecture, we'll get it automatically and not have to develop it ourselves.

Pleas stop dickering about religion about what header files one "has business" with and put back the headers that had been there up until the most recent release which are most assuredly usable and useful for user-land programs.  Thank you.

(In reply to comment #4)
> Hm - Guess I disagree with that statement.  Kernel headers are headers that
> either:
> 
> 1) Define prototypes for O/S internal functions that cannot be called from
> user-land
> -or-
> 2) Define functions that use machine instructions that cannot be executed at
> user-land privilege levels
> 
> unaligned access falls into neither of these categories.
> 
> Any user-land application that needs to deal with unaligned access most
> certainly does have business using these headers, which is why they were in
> /usr/include/asm up until RHEL 5.

No, they were there because the kernel-private headers weren't cleaned up enough and they were accidentally exposed. We've cleaned that up now.
 
> In terms of your macro, first, you mis-typed it (it won't compile as you typed
> it as one gets an illegal cast from void* to <annonymous struct>. 

It certainly compiles for me.

> The point of using a glibc supplied header is to ensure portability and
> performance when porting from one architecture to another. 

You misunderstand. This was never a glibc-supplied header. It was a kernel-private header, and now it is gone. Actually, the macro I used above was taken from /usr/include/bluetooth/bluetooth.h, where it's also a private implementation detail and not part of the public API. If you'd been abusing it from there, and then later found it went away, would you have filed a bug against the bluez-libs-devel package to have it reinstated?

I am no longer maintaining the glibc-kernheaders package, so I cannot respond directly to your request -- but I find it very unlikely that the file will be reinstated.

I hope I have provided sufficient assistance for you to correct your program, and I hope you can learn from the experience and improve your code in future; relying on private APIs which are only exposed by accident is not good engineering practice.

> unaligned access falls into neither of these categories.

Unfortunately, that is not a good assumption.  There is _no_ requirement that a Linux kernel arch provide support for misaligned data in userspace - and not
all do.  It is perfectly feasible for some arches to provide null misalignment
wrappers and then do the actual work in the misalignment fault handler, and
then to _only_ do it for kernel code (userspace will get a SIGBUS:BUS_ADRALN).

So you may not rely on the misalignment handlers in /usr/include/asm/ and
/usr/include/linux/ as there is no guarantee the functions/macros you find
there will actually work in userspace.

Please have your manager contact me.

My email is in my login.

You have not been helpful in the least.  You have in fact abused your position as tech support to promote your own ideology regarding something as silly as header files.

Your positions are ridiculous and have no basis in fact.  Our coding is just fine, thank you very much.  It is your attitude that requires some learning.

No API that is exposed in the standard include directories is private, by definition.

Your attitude is offensive and obstructive and I wish to speak to your manager regarding your lack of attention to your customer's needs ASAP.

Eric, you are perfectly free to advocate for the linux kernel community providing user space macros to help your code, but you should do that on public mailing lists (like the linux kernel mailing list).

The kernel architecture files (specifically for Intel architecture) have been drastically reworked and some files have been deprecated, rename, moved, etc. Any user space code that makes assumptions on these files is living on dangerous ground.

Just a quick update - we did some consulting with the maintainer of glibc and there is no such supported interface today at that level either (and no plans to add one).

What you seem to be looking for is a supported & usable way to have applications handle unaligned access. There is no defined standard for ANSI C or C++, officially supported glibc interface or other linux user space function that I know of that does this today.

The kernel header files are not intended to be used by user space applications unless those applications are intrinsically tied to the kernel and its data structures (applications like file system utilities, things that poke at device state, software raid, etc).

Note that many of those kernel header files also are licensed under GPLV2 (not the LGPL) so you probably do not want to compile any non-GPL code against them.

Regards,

Ric