Re: madvise() first draft

Matthew Wilcox (Matthew.Wilcox@genedata.com)
Thu, 26 Aug 1999 13:55:01 +0200


On Wed, Aug 25, 1999 at 09:28:55PM -0700, Zack Weinberg wrote:
> The way it currently works is: after your patch is added to the
> official kernel, glibc will add the defines to <bits/mman.h> and the
> syscall stub to the library. Note that madvise() is already a
> function in libc you can call - it happens to do nothing but return -1
> with errno set to ENOSYS, but it's there...
>
> We've been round and round the duplicate info in kernel and libc
> headers problem many times, and this is the least bad solution
> anyone's come up with to date.

It is? How about:

linux/include/public/foo.h
contains all constants and similar which should be exported to userspace.

linux/include/linux/foo.h
does #include <public/foo.h> and then contains kernel-specific stuff.

We would also require public-asm being a link to public-asmXXX for each
architecture XXX.

Then return to the symlink solution where /usr/include/linux is a symlink
to /usr/src/linux/include/public and /usr/include/asm is a symlink to
/usr/src/linux/include/public-asm.

Surely this cures all the problems? This split would enable glibc
to keep copies of the kernel headers more easily too, if the symlink
solution is not acceptable.

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/