From: David Woodhouse <dwmw2@infradead.org>
To: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
Cc: Russell King <rmk@arm.linux.org.uk>, linux-kernel@vger.kernel.org
Subject: Re: bitops.h ifdef __KERNEL__ cleanup.
Date: Thu, 19 Jul 2001 22:53:32 +0100 [thread overview]
Message-ID: <11472.995579612@redhat.com> (raw)
In-Reply-To: <917E9842025@vcnet.vc.cvut.cz>
In-Reply-To: <917E9842025@vcnet.vc.cvut.cz>
VANDROVE@vc.cvut.cz 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.
> 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
next prev parent reply other threads:[~2001-07-19 21:55 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-19 19:21 bitops.h ifdef __KERNEL__ cleanup Petr Vandrovec
2001-07-19 18:37 ` Russell King
2001-07-19 21:53 ` David Woodhouse [this message]
2001-07-20 4:18 ` H. Peter Anvin
2001-07-21 6:41 ` Jeff Garzik
2001-07-27 5:05 ` Eric W. Biederman
-- strict thread matches above, loose matches on Subject: below --
2001-07-19 12:54 Petr Vandrovec
2001-07-19 11:48 ` Russell King
2001-07-18 22:54 David Woodhouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11472.995579612@redhat.com \
--to=dwmw2@infradead.org \
--cc=VANDROVE@vc.cvut.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.