User: Password:
|
|
Subscribe / Log in / New account

The kernel and the C library as a single project

The kernel and the C library as a single project

Posted Dec 1, 2010 8:50 UTC (Wed) by jakub@redhat.com (guest, #31780)
Parent article: The kernel and the C library as a single project

AFAIK new syscalls are added to glibc quite fast, sometimes even faster than the kernel people actually make up their minds on the syscall ABI, so there are various issues when syscalls keep changing ABI or are dropped altogether. It doesn't help much that the kernel people are so creative
on finding out how to pass arguments to the syscalls (e.g. for simple stuff like passing 64-bit integral arguments to syscalls there are at least dozen different ways how syscalls do it - the issues related to say passing long long arguments in 32-bit ppc ABI on non-even positions which forces a padding argument register are known for years, but the approaches how to pass such arguments keep constantly changing). For ABI stability the only thing glibc needs is assurance of the syscall ABI and that it is not going to be removed the next day.

I'd also say that understanding libc as just a set of syscall wrappers is great misunderstanding of libc complexity.


(Log in to post comments)

The kernel and the C library as a single project

Posted Dec 1, 2010 10:51 UTC (Wed) by dgm (subscriber, #49227) [Link]

> I'd also say that understanding libc as just a set of syscall wrappers is great misunderstanding of libc complexity.

Indeed, there are reasons for glibc being so big in the first place. Also, many functions of the libc have to be optimized by hand for each target platform, often writing them in assembler. Do the kernel developers really want to put such a burden over their own shoulders?


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds