On Fri, Jul 13, 2012 at 4:13 PM, Dmitry Golubovsky <[email protected]> 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
