These utilities are quite few in number - you can probably count them on the
fingers of your two hands. If you weigh this against the large number of
programs that do _not_ need to interoperate with the kernel headers and would
benefit from not being so tightly tied to it, they are very much in the
minority. Also, on the whole they are maintained by the same people who
maintain the kernel-side code and so it's easy to synchronise updates.
It is acceptable for the NFS tools to need updating when there is a new major
kernel release, because by their very nature they are tightly bound to it. It
is far less desirable for some random application vendor to have to issue a
new release because some kernel structure changed its layout and old binaries
have been broken, or somebody tidied up one of the kernel headers and it no
longer compiles. The user programming API and the kernel programming API are
quite distinct - glibc provides the former, and the kernel itself provides the
latter (which glibc then uses internally).
Yes, you've seen breakage reported on this list - but this is a development
list, and breakage of one sort or another gets reported here pretty often.
The problems people have been having with NFS are no worse than anything else
that goes on during a development kernel series.
>Even when things start to settle a bit it looks like in a future hitting
>'make' with a new releas of Samba, say, will be an extremely risky
>proposition. "This source is using gid_t. But wait, in this place this
>has to be 'kernel gid_t' and few lines further this is 'glibc gid_t';
>it is used in a library function call! Run away! 'kernel gid_t' was
>just changed to a type 'foo' in the lastest kernel sources release!".
This is only an issue at the moment because we have kernel utilities around
that aren't aware of the distinction between these types. Once these future
releases of Samba or whatever are correctly using kernel_gid_t then there will
be no problem, even if either glibc or the kernel change their GID
representation.
>So why all these troubles? What this is exactly expect to buy us
>for all current and future headaches?
It buys us fewer headaches and greater flexibility in the future, at the
admitted expense of some headaches now. It also buys us the ability to
provide a user programming environment that conforms to whatever standards the
user wants, without having to screw with the kernel headers and probably break
hundreds of existing applications.
p.