lkml.org 
[lkml]   [1998]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: baffled by glibc
From
Date
>>>>> "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


\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.069 / U:1.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site