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/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:23 EST