Linus Torvalds <torvalds@transmeta.com> writes:
> So don't complain if I'm not interested in some esoteric glibc issue that
> I find totally removed from the kernel.
>
> In particular, why curse at me when it's your own problem.
It's a problem caused by you and the short-sighted way the kernel
interfaces are designed so that they need constant attention. You are
unwilling to cooperate in any way. Saying that writing a kernel
version of sysconf/fpathconf is *my* problem is simply ridiculous.
According to your logic it is my problem to keep the libc interface
and it is my problem to keep (ehm, make) the kernel interface sane.
You are happy living in the kenrel-only world. Probably using a shell
kernel module or so since, as you mentioned, the libc problems are
only "esoteric" problems for you.
Why are you constantly rejecting advices and even implementations of
proper interface for the kernel? I know that you don't think it's
fair to compare yourself to the developers of the other (commerial)
Unix kernels. But how about just taking a look at the interfaces?
Why do you think they have, for instance, kernel sysond and fpathconf
interfaces? The reason is very similar to the situation we are in
here: they have separate groups working on the kernel and user-level
stuff, they allow the admin to reconfigure the kernel. This all cries
out loud for a sane and stable interface.
If you don't want to work on these things, fine, nobody can blame you.
But I think you owe it to all the other people working on and using
the system to listen to their comments and accept some changes for
which you in the kernel-only world see absolutely no need.
Having said this it is I think time to call for volunteers ones again.
Maybe we can actually find some if you are stating that you are
actually willing to seriously consider using what they are coming up
with. What is needed is:
- very clear markings of the data structures in the kernel headers which
can be used at userlevel. Tools of whatever fashion can then be used
to extract them. I agree that the headers definitions should not
affect the possibility to run the application on other platforms and
you'll find in glibc plenty of code just to allow this. We are always
proposing to use the very latest kernel headers even if the kernel
which is actually used is very old.
- write interfaces to get kernel parameters. This must come in two
flavours:
- sysconf-like for generic parameters like
NGROUPS_MAX
ARG_MAX
OPEN_MAX
CLK_TCK
NSIG (I know that you don't think more than 64 signals are useful
but people can and do reconfigure the sources)
total number of processors
online processors (parsing /etc/cpuinfo, as we do it now, is a pain)
MSGMAX
and possibly more in future. All these are kernel related and can
be reconfigured. Just recently I've rewritten parts of the group
handling in glibc since using a constant NGROUPS_MAX is not possible.
There are people changing the constant and recompiling the kernel.
We are even doing this in-house for some special purpose machines.
- fpathconf-like
must handle something like
LINK_MAX which varies with the filesystem
- design interfaces and data structures with a little bit of
farsightness. I know you want to keep the resource requirements
as low as possible and this is fine. But being limited by existing
APIs which cannot be changed is worse and finally adds more baggage
since you have to drag compatibility code around with you.
Please consider these advices.
-- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------- 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 : Thu Jul 27 2000 - 14:13:55 EDT