Messages in this thread | | | Date | Wed, 23 Dec 1998 21:44:23 +0100 (MET) | From | (Guest section DW) | Subject | Re: <fcntl.h> vs <asm/fcntl.h> - total mess. |
| |
From: Tigran Aivazian <tigran@aivazian.demon.co.uk>
I would be glad to hear someone correcting me but as I see it - the situation is a complete mess. The O_xxx flags for open(2) are duplicated in the glibc2's <fcntl.h> and the kernel's <linux/fcntl.h> (or <asm/fcntl.h> the same). So, if I now implement O_NOFOLLOW or O_NONAME as an enhancement to open(2) it is not immediately visible to user space. And if I force user app to #include <asm/fcntl.h> then it will lose other important things, like R_OK, W_OK etc, which are in <fcntl.h> (well <fcntlbits.h> actually) but not in <linux/fcntl.h>. And I won't get declaration of open(2) that way.
Why are not glibc2 maintainers include <asm/fcntl.h> from <fcntlbits.h>, just like <resourcebits.h> includes <asm/resource.h> or <socketbits.h> includes <asm/socket.h>?
What is wrong with asking glibc2 maintainers for /usr/include/fcntlbits.h to include <asm/fcntl.h>? (and then sorting out all the conflicts like FASYNC and flock redefinitions, of course).
The kernel include files are for compiling the kernel, and for no other purpose. It is very unwise for a user application to include them - even if it compiles today, it will fail to compile tomorrow.
People complain that util-linux does not compile on an alpha. Why? <sys/io.h> includes <asm/io.h> includes <asm/machvec.h> and the latter consists of kernel-only junk. This situation is typical - there are hundreds of examples.
So, you must not ask the glibc maintainer to include more kernel junk, but you must be happy that very slowly glibc succeeds in avoiding more and more kernel stuff.
If you need the very latest kernel features and cannot wait for the next release of glibc, you have to make do with a private copy of the constants you need, prehaps protected by an ifdef on the kernel version and/or an ifndef so that they are not defined twice.
Andries
- 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/
| |