Messages in this thread | | | Subject | Re: baffled by glibc | From | (Eric W. Biederman) | Date | 18 Jan 1998 13:27:35 -0600 |
| |
>>>>> "MJ" == Michal Jaegermann <michal@ellpspace.math.ualberta.ca> writes:
MJ> Can somebody explain why this header separation between glibc and kernel, MJ> touted as "the best thing from a sliced bread", is really such a good MJ> thing? The only answer I have seen so far is that this will allow MJ> independent changes of various structures and definitions in kernel MJ> headers.
MJ> That is the point! A lot of system utilities **has** to know these sizes.
The trouble is that glibc doesn't completely encapsulate the kernel/user interface.
And as you have said it is system utilities. Previously what would happen when any of these kernel things changed (like mode_t, uid_t, etc) was _all_ user level programs would break. Not just the system level ones.
Now the user level is doing to the system utilities what upon occasion the kernel did to the user level, break programs.
MJ> So far I have seen on this list a breakage in NFS, ncpfs, smbfs caused MJ> by a mismatch in definitions between these two sets of headers and tons MJ> of time wasted in heroic efforts to discover what is causing strange bugs MJ> (with some voices pipin in "It works for me" but they have still previous MJ> libraries/headers). [snip]
MJ> 'make' with a new releas of Samba, say, will be an extremely risky MJ> proposition. "This source is using gid_t. But wait, in this place this MJ> has to be 'kernel gid_t' and few lines further this is 'glibc gid_t'; MJ> it is used in a library function call! Run away! 'kernel gid_t' was MJ> just changed to a type 'foo' in the lastest kernel sources release!".
If there is a function that stands betwee the kernel interface and the user interface this isn't a problem.
MJ> So why all these troubles? What this is exactly expect to buy us MJ> for all current and future headaches?
We will never break user level utilities again && we can do things we would never have dared to do before (at least consider). Say move to a 32 bit dev_t. If glibc was the only game in town it would be a trivial change to make. But libc4 & libc5 still exist :(
The point is that except for the small class of system utilities kernel changes can no longer break programs.
It's not the greatest thing since sliced bread, but it works. The real challenge is there are now _TWO_ interfaces to support, and most developers it appears haven't begun to support the glibc2 interface.
Eric
| |