Re: madvise() first draft
Zack Weinberg (zack@bitmover.com)
Wed, 25 Aug 1999 21:28:55 -0700
Chuck Lever wrote:
> On Wed, 25 Aug 1999, Jeff Garzik wrote:
> > Did you check how things are set up on a Linux system?
> >
> > On RH6.0, sys/mman.h includes bits/mman.h, and so references no kernel
> > code at all. On RH5.2, sys/mman.h includes linux/mman.h, which in turn
> > includes asm/mman.h.
>
> right -- i didn't expect that the user-level headers would include any
> kernel headers. they will likely have duplicate definitions of the MADV
> macros, just like everything else.
>
> > Either way a common location for these constants seems desireable. If
> > there are platform-specific differences you can always provide a default
> > set of constants in include/linux, and override them with arch-specific
> > code if need be.
>
> i agree, but i'm not sure madvise is the place to start. it would be
> confusing to have madvise work that way, but nothing else. in other
> words, what you are proposing seems like a bigger project that i don't
> want madvise to get stuck behind, if you know what i mean. on the other
> hand, i'm not familiar with how new system call stuff gets added to glibc
> and user-level headers, so it may not be difficult at all.
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.
zw
-
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/