Messages in this thread | | | Date | Thu, 27 Jul 2000 18:25:14 +0200 | From | Jamie Lokier <> | Subject | Re: RLIM_INFINITY inconsistency between archs |
| |
Ulrich Drepper wrote: > Linus Torvalds <torvalds@transmeta.com> writes: > > I expect that library versions and compiler versions should matter to > > compiling programs. But I do _not_ want kernel versions to do that. It's > > already painful for people that you have to have the right library > > version. I'd _hate_ to see source code that says "requires kernel 2.3.99 > > or higher sources in /usr/src/linux" in addition to saying "needs > > glibc-2.1.2 or newer for threading reasons". > > I cannot except any of your accusations. Your style of development > these sudden, unplanned changes is what makes it necessary to not add > all the content to the libc headers.
Um, changes to the kernel do _not_ affect user-kernel API. Well, they shouldn't anyway. They just add more features, which newer user-space can use if it knows about them. So what is your reason for having to release a new Glibc every week?
> Until you provide solutions for this you cannot expect others to do > more work. I would have to release a new glibc version every week > since something changed and somebody will run into the problems. And > no, your argument that the people who are doing such low-level work > should know what to do doesn't cut.
The subject of this thread is RLIM_INFINITY. There's an example that wouldn't be a problem at all if you didn't include kernel headers.
> In addition, and I repeat this probably for the thousands time, where > the f*ck is the sysconf() functions which is so very much needed?
Something for a separate thread...
> Those people might know, but what they produce and ideally distribute > in source form has to be compiled by the clueless. They don't know > how to change their system (if they even have the permission) and > hardcoding new values is also out of question.
Why is hardcoding a kernel-user API, which is set in stone by binary compatibility requirements anyway, out of the question? They can be hard coded in the distributed source, so that clueless users don't need to know anything.
Hmm... well that doesn't really explain why pppd comes with copies of the kernel headers but will use ones from the installed kernel if they're newer... Why is that?
> Maybe you should spent some time thinking how *you* can improve the > process of using more recent kernels before complaining about others. > The first and obvious thing is to implement __sys_sysconf (maybe do it > on top of sysctl, I don't care).
Using a new kernel is easy. Compile, install, reboot. Provided the Glibc headers don't point to the new kernel's headers it works fine :-)
-- Jamie
- 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/
| |