On Sat, 2006-04-22 at 16:44 +0200, Adrian Bunk wrote:
> The problem is you need #ifdef's everywhere.
No. You don't need ifdefs _anywhere_. Go and take a look at the MTD
headers which I already cleaned up.
You can split the messy files into two (or more) files and _keep_ them
in the same directory structure, although admittedly I did move the
user-visible parts out into include/mtd/ -- with the 'headers_install'
make target I didn't need to do that though.
> If part of a header file is part of the userspace ABI, this often means
> that you need #ifdef __KERNEL__'s for the #include's of headers that
> will not be part of the userspace ABI (like linux/compiler.h).
Er, if you're including those headers in a _purely_ user-visible file
then they're an error and should be removed altogether.
And if you're including those headers in a file which already _has_ some
ifdef __kernel__ in it, then you can just move the inclusion so that it
lands within the existing ifdefs. Like this, for example:
http://git.infradead.org/?p=users/dwmw2/headers-2.6.git;a=commitdiff;h=90a333de75b3f5efdc332f34f53768286967c306
> And how do you express that in header foo.h, the userspace part requires
> the userspace part of bar.h, while the kernel-internal part of foo.h
> also requires the kernel-internal part of bar.h?
You use foo-user.h, and foo-kernel.h. Or you include <kabi/foo.h> from
linux/foo.h if you can get Linus to take the patches. Nothing prevents
you from doing that. Please do that if that's what you want.
> I'm sorry, but I don't like your approach.
OK. This approach lets you send patches to Linus to move user-visible
stuff into a kabi/ directory if you can actually get him to accept such
patches. It allows you to move stuff over to a kabi/ directory
incrementally, without having to move everything in one go -- the export
process can pick files from wherever they happen to be, and put them in
the appropriate place in the exported header tree.
This approach _also_ allows those of us who are being more realistic to
do slightly less ambitious work which is just as useful but more likely
to get accepted, because we do the same cleanups to the _code_ but
without mucking around with new directories.
But we're open to alternative plans -- what approach would you prefer?
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
