On December 30, Mike Andrew enlightened our ignorance thusly:
> On Sun, 30 Dec 2001 05:12, Collins Richey wrote:
> > <rant>
> > It would surely be nice if the compiler and library folks could make
> > progress without breaking old things. I still remember (not too fondly)
> > all the havoc that the current glibc generated when it was new.
> > </rant>
>
> <double rant squared>
>
> THE problem with glibc is that is not a General Library of C at all but a
> truly confused mish-mash of kernel only specifics and userland generics. A
> *general* C library is just that. It contains agnostic code such as printf(),
> strcpy() and others, uses standard headers such as <ctype.h> . It does not
> have stupidites in it for kernel locking semaphores, and equally ridiculous
> and constantly changing header files. If anyone can ever explain to me what
> the kernel only printk() statement is doing in a *general* library, I'll
> learn Visual Basic as a punishment.
Umm, printk() is not defined in glibc. It is defined in
kernel/printk.c and uses only system headers
(linux/{mm,tty,tty_driver,smp_lock,console,init}.h and
asm/uaccess.h).
> The idea behind a *general* library is to add functions that can *generally*
> be used. Explain that sentence when kernel code for now-useless SYN packets
> is a 'good idea'.
>
> No better example of the bastardisation they've caused is the requirement to
> compile using a *general" c library for the 'kernel' and another *general* c
> library for kde and another *general* c library for redhat. The idiocy of a
> 'general' set of headers in /lib versus a 'general' set of headers for
> /usr/src/linux, versus an obsolete (but general) set of headers for 'legacy'
> api's. (ie ones they don't want to fix anymore, thinking of something even
> more brilliant)
I'm not following you here. In particular, I'm confused by "'general'
set of headers in /lib versus a 'general' set of headers for
/usr/src/linux, versus an obsolete (but general) set of headers for
'legacy' api's)." In the first place, I need a concrete example to
make sense of your argument. Secondly, and in the meantime, I'm
baffled - you (rightfully) gripe about unwise linkage between the C
library, the kernel, and other APIs, yet, in the same paragraph,
complain that the interfaces and functions are defined in such a way
to minimize that linkage. You can't have it both ways, my friend.
There have been a number of discussions on l.k.m.l. about creating a
non-GNU C library... Linus has ranted more than once about the glibc
maintainers building stupid dependencies into the C library. Happily,
the kernel developers themselves have largely kicked the habit of
depending on broken glibc code, glibc misfeatures, and so forth.
Unfortunately, the kernel continues to rely on GCC-isms, a situation
Linus himself introduced and seems loathe to give up. That said,
creating a C library from scratch is non-trivial, as I'm sure you
understand.
> If you accept that 90% of truly *general* c functions have worked since year
> dot, that 10% of those get 'improved' and that 10% of the improved ones cause
> problems, those problems are insignificant. To mix this with 'improved'
> kernel functions is either an excercise in stupidty, or much more probably,
> and indictment of anal retentivity. They can't let go. We pride ourselves on
> slapping at Microsoft. Idiocy is often closer to $home.
>
> This situation will never improve, nor resolve, until the control-freak
> mentaility is removed from gcc / glibc. The kernel is NOT general and until
> it is removed from glib we will continue to live in interesting times. No
> real world busines would ever accept this degree of instability, they'd be
> fired.
Agreed. I'd love a non-GNU C library with no linkage to kernel code
or these "legacy APIs" to which you refer (I presume you're talking
about SysV IPC, for example). However, this begins to get into the
matter of hosted versus non-hosted C implementations, which is the
stuff of madness for all but the standards committees that create
these monsters.
Kurt
--
"Well, if you can't believe what you read in a comic book, what *___can*
you believe?!"
-- Bullwinkle J. Moose [Jay Ward]
_______________________________________________
Linux-users mailing list
Archives, Digests, etc at http://linux.nf/mailman/listinfo/linux-users
