Messages in this thread | | | Subject | Re: sysconf (was Re: RLIM_INFINITY inconsistency between archs) | From | Ulrich Drepper <> | Date | 27 Jul 2000 11:07:57 -0700 |
| |
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/
| |