[systemd-devel] [HEADSUP] New module ‘libc’ in systemd git

[Lennart Poettering]

Heya,

I just added a new module to systemd git, “libc”, and you are probably
wondering what that is about. Here’s a quick overview over what this is
and our plans with it.

We figured to complete the systemd project we were still lacking an
email program[1]. In order to get this off the ground quickly we noticed
we’d need a libc first. We had the option of either merging glibc into
systemd, or write a new C library. Of course, we are pretty good at
rewriting existing programs (we are simply faster doing that, since we
don’t have to read so much code), so we opted for the latter. The new
module ‘libc’ is the result.

Technically, this move makes perfectly sense, too. We are sick of
supporting unstable glibc APIs and ABIs, and we believe that we greatly
benefit from the fact that we now finally have everything the OS
userspace consists of in one single repository.

Of course, this new libc is not available to Ubuntu and other Linux
distributions that have not yet adopted systemd. However, after
deliberately choosing a home-grown display server (Wayland) over the
generally accepted one (Mir) we decided creating an incompatible libc
would be the best approach to create a strong platform following a
strict release cadence.

The current code is fairly limited. We hope to have something workable
by systemd 205 or so, and will then slowly move systemd’s own code over,
external programs can follow. We target Fedora 22 as first distribution
to adopt our libc for all packages. Given the shortcomings of the
current glibc development process we expect no opposition from
FESCO. Also, we expect that our friends from ArchLinux will port their
distribution over by systemd 204 already. Debian and Gentoo are likely
to support this new libc in addition legacy eglibc in parallel for a few
more years.

This new libc will expose all kinds of Linux-only functionality, and
will depart from the limited POSIX APIs for that. This will probably
mean compatibility with glibc systems will be dropped within a couple of
releases.

To make this new library exciting to developers we added a couple of new
calls that fix long-standing problems in glibc. For example, first of
all we added strlcpy() as known from OpenBSD. We also renamed the API
call “creat()” to “create()”, as modern operating systems do not have
the strict limitation on system call name lengths the way UNIX System 7
had.

Anyway, that’s all for now. If you have questions, or want to help
getting this off the ground, please ping us on IRC.

Thanks,

Lennart

Footnotes:

[1] We can add a kernel later on, following the GNU/Hurd’s successful
approach.

-- 
Lennart Poettering - Red Hat, Inc.