bitops.h ifdef __KERNEL__ cleanup.
Quoted 5 lines · Russell King
I totally disagree here. We already say "user space should not include kernel headers". Why should
bitops.hbe any different? Why shouldatomic.hbe any different? They contain architecture specific code, yes, which may not work in user space.
Maybe because of I do not know ARM assembler? If you do not want kernel headers to be used in apps, just move them from asm and linux into msa and xunil. Then you can simple remove all #ifdef __KERNEL__ from them...
Quoted 2 lines
Oh, and thanks for pointing out ncpfs breaks - I hope the authors will fix up their sloppy coding before Davids patch makes it into the kernel.
It will still work. Only resulting binary will be slower. That's what autoconf is for. If ncpfs does not compile for you, better to contact me directly, as I'm ncpfs maintainer...
Best regards,
Petr Vandrovec [email protected]
P.S.: Part of ncpfs's configure.ac. I do not think that it is that hard...
AC_CACHE_CHECK(for working asm/atomic.h,
ncp_cv_asm_atomic_h,
AC_TRY_LINK([#define __SMP__
#include <asm/atomic.h>],
[atomic_t a;
atomic_set(&a,2);
atomic_dec(&a);
if (atomic_read(&a)) {
if (!atomic_dec_and_test(&a)) {
atomic_inc(&a);
}
}],
[ncp_cv_asm_atomic_h="yes"],
[ncp_cv_asm_atomic_h="no"]
) )
if test "$ncp_cv_asm_atomic_h" = "yes"
then
AC_DEFINE(HAVE_ASM_ATOMIC_H, 1, [Define if we have working asm/atomic.h])
fi
Quoted 4 lines · Petr Vandrovec
Maybe because of I do not know ARM assembler? If you do not want kernel headers to be used in apps, just move them from asm and linux into msa and xunil. Then you can simple remove all #ifdef
__KERNEL__from them...
Why should the kernel change to please a problem minority in user space who shouldn't be including kernel headers in the first place?
Quoted 3 lines
It will still work. Only resulting binary will be slower. That's what autoconf is for. If ncpfs does not compile for you, better to contact me directly, as I'm ncpfs maintainer...
No. The binary _will_ not do what you expect - these functions are not atomic in user space on all architecture types. Yes they may work, but not with the atomic side effects. You won't get this from a simple autoconf test.
I'll give you credit though - you're at least checking that they appear to exist; I have come across many programs which rely on them existing, and do not check that they exist.
It is these that David and myself wish to target, and this along with the general rule of "Never include kernel headers in user code", it seems to be the most appropriate solution.
Now, there is a nice clean solution to your problem - bug the glibc people to provide equivalents in their library, hopefully as inline asm in the systems header files. Systems which need to do extra stuff can then have them implemented in the C library.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
Quoted 3 lines · [email protected] said:
If you do not want kernel headers to be used in apps, just move them
from asm and linux into msa and xunil. Then you can simple remove all #ifdef__KERNEL__from them...
It has been stated many times that kernel headers should not be used in apps. Renaming or moving them should not be necessary - and people would probably only start to use them again anyway. We'd see autoconf checks to find whether it's linux/private.h or xunil/private.h :)
In the absence of any expectation that userspace developers will ever obey the simple and oft-repeated rule that you don't use kernel headers from userspace, the #ifdef __KERNEL__ approach would seem to be the best on offer.
Quoted 2 lines
P.S.: Part of ncpfs's configure.ac. I do not think that it is that hard...
I'm not very familiar with autoconf, but doesn't the snippet you pasted just check that the program compiles and links? It won't notice if you build a binary with privileged instructions in, or one which just fails to provide the correct semantics when the routine is used in a environment for which it was not designed?
Where is this used in ncpfs that it makes _such_ a difference?
--
dwmw2
Followup to: <[email protected]> By author: David Woodhouse <[email protected]> In newsgroup: linux.dev.kernel
Quoted 11 lines
It has been stated many times that kernel headers should not be used in apps. Renaming or moving them should not be necessary - and people would probably only start to use them again anyway. We'd see autoconf checks to find whether it's
linux/private.horxunil/private.h:)In the absence of any expectation that userspace developers will ever obey the simple and oft-repeated rule that you don't use kernel headers from userspace, the #ifdef
__KERNEL__approach would seem to be the best on offer.
Note that the rule is at least in part theoretical; even glibc include kernel headers or -derivatives.
I think the idea with <asm/bitops.h> is that they are protected by #ifdef __KERNEL__ if they are kernel-only; however, if they work in user space then there is no #ifdef and autoconf can detect their presence.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt
Quoted 9 lines · H. Peter Anvin
Followup to: <[email protected]> By author: David Woodhouse <[email protected]> In newsgroup: linux.dev.kernelQuoted 6 lines
It has been stated many times that kernel headers should not be used in apps. Renaming or moving them should not be necessary - and people would probably only start to use them again anyway. We'd see autoconf checks to find whether it's
linux/private.horxunil/private.h:)
Quoted 7 lines
Quoted 4 lines
In the absence of any expectation that userspace developers will ever obey the simple and oft-repeated rule that you don't use kernel headers from userspace, the #ifdef
__KERNEL__approach would seem to be the best on offer.Note that the rule is at least in part theoretical; even glibc include kernel headers or -derivatives.
Derivatives are fine and IMHO irrelevant to the issue of __KERNEL__:
you can always do something like gcc's fixincludes.
uClibc and dietlibc do not include any kernel headers at all. And at least one glibc developer spoke up in a previous thread and agreed that it is not necessary to include kernel headers in glibc.
As important as glibc is, it's breaking a rule, which is a bug, that can be fixed.
Quoted 4 lines
I think the idea with <
asm/bitops.h> is that they are protected by #ifdef__KERNEL__if they are kernel-only; however, if they work in user space then there is no #ifdef and autoconf can detect their presence.
Any amount of sharing between userspace and kernel -adds- constraints to kernel code, and leads to namespace pollution on both ends by careless (or busy!) developers.
Let's remove restrictions and constraints from kernel code, not add to them...
Signature · 3 lines
Jeff Garzik | "I wouldn't be so judgemental Building 1024 | if you weren't such a sick freak." MandrakeSoft | -- goats.com
Quoted 11 lines · Jeff Garzik
Quoted 4 lines
I think the idea with <
asm/bitops.h> is that they are protected by #ifdef__KERNEL__if they are kernel-only; however, if they work in user space then there is no #ifdef and autoconf can detect their presence.Any amount of sharing between userspace and kernel -adds- constraints to kernel code, and leads to namespace pollution on both ends by careless (or busy!) developers.
Let's remove restrictions and constraints from kernel code, not add to them...
Sounds reasonable. Do you think you can get them to remove /usr/include/linux, and, /usr/include/asm in the next release of Mandrake?
Eric