Bug 63643
| Summary: | Missing begin comment in /usr/include/asm/atomic.h | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Public Beta | Reporter: | Blair Zajac <blair> |
| Component: | glibc-kernheaders | Assignee: | Arjan van de Ven <arjanv> |
| Status: | CLOSED RAWHIDE | QA Contact: | Brian Brock <bbrock> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | skipjack-beta2 | CC: | ian, jakub, jerenkrantz |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2002-04-16 18:15:35 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Blair Zajac
2002-04-16 18:15:30 UTC
Yup, fixed already. However nothing should ever include atomic.h though..... The Apache Portable Runtime (http://apr.apache.org) explicitly includes this file in include/apr_atomic.h. Best, Blair Yuck APR is broken. Very broken. It makes assumptions that are just not true..... what assumptions does it make?
it looks like the current 'standard' kernel version of atomic.h is different
to redhat's ('beta') version
is there a actual reason for this (bug#)
1) it makes the assumption that those functions are also atomic in userspace, which isn't the case actually (not even on i386) 2) it makes the assumption that those functions compile in userspace, which isn't the case all architectures (some architectures need to use spinlocks for this since the cpu doesn't have the atomic ops themselves) 3) this is not a kernel header. It's a glibc header which happens to be derived from the kernel. There reasons for the header to be different: 1) it doesn't do what people think it does resulting in nasty bugs (see #1 above). Our developer support department had several nasty cases with this. 2) it's a kernel private header. there's NO guarantee about this not breaking for different kernel versions. The glibc headers package however is there to provide a stable API for userspace. This means that internal, not-for-userspace headers (or parts of headers) cannot be in that since the kernel developers don't guarantee API stability in those, not even in a stable kernel series. (and esp not for userspace use) 3) There's the angle that these inlines are covered by the GPL license. Programs using them would therefor include compiled gpl code in their binary, which is a legal minefield at best Our biggest concern is that Linux doesn't have any userspace atomic interface (such as FreeBSD-CURRENT does). I have submitted a patch to the APR development list to use handcoded assembly (based on FreeBSD's assembly code since APR can't touch the Linux source code), but I really feel that this is something that the core OS should be handling. jerenkrantz: I agree, however that would be a glibc task, not a kernel one; you don't want a syscall for every atomic operation.... |