On Tue, 29 Jun 1999, Evan Van Dyke wrote: > *SNIP* > > However, I expect I'm the only one who thinks that's the proper > > approach so, how's this for a solution: Give the /usr/include/asm and > > /usr/include/linux directories up as lost causes. Instead, define new > > directories. Say /usr/include/kernel-asm and /usr/include/kernel-linux. > > Make THEM symlinks to the appropriate directories in the kernel source > > tree. I would do this on my own computer, but I don't really get any > > benefit from it unless everyone else, particularly those who develop > > modules and whatnot, decides to use the same convention.
> > Therefore, we then attempt to convince people to actually use those > > directories instead of /usr/include/asm and /usr/include/linux for the > > good reasons that we've discussed. > If you havn't read the letter by Linux Torvalds that was referred to under > this thread within the last few days, I suggest that you do so. I read it. In fact, the message that you quote was primarily in response to that message. I UNDERSTAND the problem. I solved similar problems back 15 years ago when I first started debugging clibs. It's the solution that I find lacking. Too bad you didn't quote the part of my message that was really important: Making my life tougher because it's easier for me to deal with it than Joe Random Luser is NOT AN ACCEPTABLE SOLUTION! Yes, I can deal with it Joe Random Luser, but I shouldn't have to. > The obvious choice seems to be /usr/src/linux/include/linux and > /usr/src/linux/include/asm as that is where most people store their > kernel source. Why clutter up /usr/include more with kernel-specific > headers? The entire point is that the /usr/include/* headers should be > kernel-independant after all. Why is that the point? If that's the point, it's a damn stupid one. Look, header files go under /usr/include and /usr/local/include. Since the header files that are kernel specific aren't local to the system, they should be accessible under /usr/include. I should be able to refer to them like that. THAT is what is obvious to me. Why clutter up /usr/include with directories containing kernel-specific headers? Well, why clutter it up with omniORB and ggi and php3? Because /usr/include and the directories underneath are where header files GO, aren't they? Having two sets of files with identical names and nearly identical contents just galls me. What do I care what kernel the glibc maintainer built libc.so.6 on? Why should I keep those files around? The real issue is one that I talked about in my original message: idempotence. While I agree that libc has to know about the kernel calls so that it can wrap them in C-standard functions, it is apparent that glibc, at least, knows far more about the internals of the kernel than is good for it. It is essential that a given version of glibc be able to run on newer kernel versions and on patched kernels. That requires careful design and some foresight, which appears to be lacking in this case. Let's take an example or two from the message from Linus Torvalds: The use of the NR_OPEN constant. The kernel (apparently---I just skimmed over it) uses NR_OPEN to set how many file handles any given task must have. That is, it allocates an array of NR_OPEN "struct file *" for each task that is forked. (The code is in kernel/fork.c, if you have a mind.) Why does glibc refer to this constant anywhere? The number of files that the kernel allows to be opened doesn't necessarily have anything to do with the number of files glibc allows you to open. I suppose that glibc might put an array of size NR_OPEN in order to hold the file handles, but that's dumb. The ISO C standard says that the constant that defines the maximum number of open files is FOPEN_MAX, and it is far smarter to put your file handle in the FILE struct and declare your FILE array to be of size FOPEN_MAX. #define FOPEN_MAX to be the same as NR_OPEN? Use the same sigset_t for both glibc and the Linux kernel? Yes, you COULD do that, but those things don't necessarily have anything to do with each other, and it is poor practice to use the same abstraction to refer to unrelated things even if they happen to be the same at some point. libc abstractions, what most programs use, are NEVER required to be the same as the kernel abstractions. While I agree that you can work around the problem by requiring that /usr/include/asm and /usr/include/linux be the contents of the directories /usr/src/linux/include/asm and /usr/src/linux/include/linux on the system used by the builder of the glibc and by requiring that the kernel source must ALWAYS be in /usr/src/linux, but that is not the correct solution. That is a massive kluge needed because people can't seem to be bothered to do things correctly. The correct solution is to eliminate those instances where constants are used for purposes that they have no business being used for. It's like defining the FOPEN_MAX to be sizeof(double) because on some computers sizeof(double) is 8 and 8 is an acceptable value for FOPEN_MAX. Yes, it works, at least some places, but it's stupid. -- Jonathan Guthrie ([EMAIL PROTECTED]) Brokersys +281-895-8101 http://www.brokersys.com/ 12703 Veterans Memorial #106, Houston, TX 77014, USA