[systemd-devel] Integration with Buildroot (uclibc-based runtime): patches suggested

Kay Sievers kay at vrfy.org
Fri Jul 13 08:21:10 PDT 2012


On Fri, Jul 13, 2012 at 4:13 PM, Dmitry Golubovsky <golubovsky at gmail.com> wrote:
> Tomasz Torcz wrote:
>
>>  Wouldn't it be better (and beneficial to others) to implement missing
>>  functionality in uclibc?
>
> I am not a maintainer of uclibc (and not a maintainer of buildroot
> either, just a contributor of few packages). I cannot answer this,
> sorry.
>
> Kay Sievers wrote:
>
>> Looks like. All of these functions seem generally useful and should
>> not be worked around in user code which relies on them.
>
> I think this is a goal of uclibc (just IMHO) not to implement every
> extension glibc has, saving on code size. Besides there are
> glibc-based toolchains for buildroot, I am just not using them.
>
> Well, OK. I suspect that there is not so much interest to accept these
> patches upstream, correct?

This is correct in most cases, yes.

We usually do not want to work around generally useful missing
functionality in other libcs; just the same way we do not like to work
around specific kernel versions or kernel bugs, or broken interfaces
which should be fixed instead.

The pain of not fixing interfaces, or not adding useful stuff to a
libc, should just kick back to the users and maintainers of the
specific kernel or libc, and not pass the burden down to the tools to
make things work.

Just like the kernel, a libc is there to serve the tools, and not the
other way around.

There is no strict rule about where to draw the line, but the things
look in your list look useful for everybody, and should be part of a
proper libc that tries to to be useful. We can surely add work-arounds
for exotic or weird things, but we do not want to do that for simple
and generally useful interfaces.

I'm generally not convinced of the idea of saving code size by
leaving-out useful things in the libc and implement them (possibly
multiple times) in the tools instead.

Thanks,
Kay


More information about the systemd-devel mailing list