[PATCH] implement futimes
Sergio M. Ammirata, Ph.D.
sergio at ammirata.net
Mon Nov 23 15:13:34 UTC 2009
Hello Rob,
Thanks for your thorough response.
NPTL:
It seems that this thread has jumpstarted the machinery to get at least the
production ready arm and sh4 into master. After that is in, maybe we can get
the x86 branch working too ....
MY LIBC MALLOC CRASH:
Regarding my malloc application crash, I appreciate your help and will start
another email thread for it.
UCLIBC DEVELOPMENT:
As far as the future of uclibc, I would really love to see additional
participation by new developers that have more spare time so that this
project can come back to life. I am sure this would also improve end user
support and bring a fresh perspective to the project.
GLIBC vs UCLIBC:
Could you explain what makes lbglv3 so bad compared to uclibc's license?
As far as perl, I already had to include about 20 modules in the microperl
config of buildroot to be able to compile all the apps included in my
firmware. Are you saying that glibc has additional dependencies on perl
beyond having perl installed in build and target-dev system? Personally, I
think buildroot should include a larger subset of perl by default.
Regards,
Sergio
On 11/22/09 5:21 PM, "Rob Landley" <rob at landley.net> wrote:
> On Sunday 22 November 2009 08:14:55 Sergio M. Ammirata, Ph.D. wrote:
>> Carmelo,
>>
>> Not to be disrespectful, but I agree with Rob's assessment. I too have been
>> using the uclibc library for more than 5 years and it's releases are few
>> and far between compared to many other open source projects.
>>
>> I have seen at least 3 other branches of uclibc being maintained by other
>> people outside the official repositories because of the slow or
>> non-existent response from the uclibc developers.
>>
>> The fact that the nptl branch is still not in the main branch is in my
>> opinion a lack of vision from the maintainers of the project. The nptl code
>> is needed in order to compile any recent version of VLC for example.
>>
>> Recently, I spent over 60 hours of work using multiple machines to perform
>> simultaneous compilations trying to get the nptl branch working on x386.
>> Unfortunately, I had to stop because the solution to the problem was beyond
>> my skillset. I am able to do some coding and prepare patches for simple
>> things and offered my time to test anything that needed to be tested to no
>> avail.
>
> Peter Mazinger once explained to me the difference between the various uClibc
> NPTL implementations and what pieces of each needed to be put together to
> unify it. Unfortunately, I don't remember the details, and Manuel Nova drove
> Peter away from uClibc development back in 2006 by complaining that the large
> number of commits Peter was making to the mainline -dev repository were
> breaking Manuel's private out-of-tree patches which he refused to commit to
> mainline.
>
> That was the point at which the uClibc development process officially
> graduated
> to "diseased", if you ask me...
>
>> I also reported an application crash that happens with the 0.9.30.1 and
>> newer libc malloc code and that was not there in 0.9.28. I could not find a
>> solution for it.
>
> Which target, what .config, what application, how do you reproduce the
> crash...?
>
> If you can reproduce it under my build system (or build with my toolchain),
> I'll debug it and fix it (in my de-facto fork, grumble):
>
> http://impactlinux.com/code/firmware/dowloads
>
> I've already had to dig into the malloc code and fix stuff that nobody EVER
> TESTED:
>
> http://landley.net/notes-2008.html#27-10-2008
>
>> The developers of the app swear that it is a bug in the
>> ulibc libraries and the uclibc developers say those types of changes of
>> behavior and normal and expected and that it is the application doing
>> something wrong (even though it is exactly the same application source code
>> in both cases).
>>
>> My point is, has the target user of the uclibc changed since its
>> conception?
>>
>> Are you guys only focusing on big companies that develop embedded devices?
>
> I'm not. I'm focusing on any developers who wants to play with non-x86
> targets under qemu, whether it's hobbyists learning or professionals doing
> emulated build clusters on cheap x86 hardware.
>
>> It would explain why there is still no support for 386 on the nptl branch.
>
> There are three different NPTL targets, written by three different people who
> didn't get to see each other's code because SJ Hill refused to check his
> original NPTL code until he got paid for it:
>
> http://ibot.rikers.org/%23uclibc/20060325.html.gz
>
>> 04:11.09 ds so I'll just slog through and debug it
>> 04:11.16 sjhill debug what?
>> 04:11.24 ds why I'm getting segfaults
>> 04:11.29 sjhill *sigh*
>> 04:11.34 sjhill you're wasting your time
>> 04:11.47 sjhill i have the 2000+ lines of patches needed to make the dynamic
>> loader work
>> 04:12.05 sjhill or are you talking just normal binaries?
>> 04:12.18 ds both, actually
>> 04:12.22 sjhill forget NPTL
>> 04:12.33 sjhill the normal stuff, that is a problem
>> 04:13.07 ds are you saying that you have stuff that's not checked into the
>> nptl branch?
>> 04:13.14 sjhill yes.
>> 04:13.17 ds ah, ok
>> 04:13.21 ds i missed that part
>> 04:13.24 ds sorry
>> 04:13.37 sjhill np
>> 04:13.44 sjhill i thought i was being clear, but guess not
>> 04:14.57 ds I can't say that I tested static binaries too thoroughly
>> 04:15.19 ds so I may have just done something blatantly stupid
>> 04:15.28 sjhill static NPTL binaries will absolutely not work
>> 04:15.34 sjhill i haven't even debugged them
>> 04:15.40 sjhill they segfault all over the place
>> 04:16.10 dalias it looks like i'm going to have to write my own pthread
>> implementation..
>> 04:16.14 dalias maybe uclibc can use it once i'm done
>> 04:16.22 dalias imo nptl is hopelessly broken
>> 04:16.27 sjhill you are an idiot
>> 04:16.42 dalias um, why do you say that?
>> 04:16.54 sjhill the reason the code is not checked in is because i did it
>> under contract
>> 04:16.59 sjhill once i get paid, the code gets released
>> 04:17.02 sjhill which is in two months
>> 04:17.12 sjhill impatient aren't we?
>
> So there you have it, S.J. Hill and Manuel Nova both kept development out of
> tree for a long time, refusing to check it in until they got paid, and the
> result was that mainline development slowed to a crawl, independent
> ("competing") attempts to implement the same functionality were kept out of
> the tree, and the longer they stayed separate the harder it got to merge them.
>
> And to this day, there are people who still insist this wasn't really a
> problem, and continue to do the same thing.
>
>> Is there someone within the uclibc developer organization maintaining the
>> priorities of the limited developer resources?
>
> In theory, the maintainer. In practice, not that I've noticed.
>
>> If so, can those be
>> communicated to the user community through the web site so that we can all
>> make an informed decision whether to continue using the library? Embedded
>> storage has become larger and larger recently and the standard glibc
>> library is no longer an outrageous choice.
>
> The main reasons I still use uClibc (other than inertia) are:
>
> 1) glibc went lgplv3, which I don't want to get on me.
> 2) glibc requires perl to build.
>
>> If it is a matter of resources, why don't you post a message on your web
>> site asking for help. I am sure there are hundreds of qualified individuals
>> that can help with the project.
>
> The problem isn't a lack of developer time. Lots of developers would be happy
> to help out. I've done it, and here's BusyBox maintainer Denys Vlasenko
> repeatedly taking an interest:
>
> http://lists.uclibc.org/pipermail/uclibc/2008-July/040588.html
> http://lists.busybox.net/pipermail/uclibc/2009-February/042022.html
>
> The problem is coordination.
>
> First of all, they decided to do the merge somewhere other than the -dev
> branch, which was either an enormous mistake in retrospect or they _meant_ it
> to take 3 years and still be stalled:
>
> http://lists.uclibc.org/pipermail/uclibc/2006-August/037013.html
>
> Secondly, the project is set up so that there are bottlenecks that only
> specific people can resolve, and those people then sit on those bottlenecks
> for
> months until somebody else is made the new bottleneck. (Oddly, this somebody
> is never the project's maintainer...) Meanwhile other people post random
> unrelated patches here in a steady trickle, wihch can never go into a release
> due to said bottlenecks.
>
> The fun part is the musical rotating bottlenecks. As noted above, sjhill was
> the NPTL bottleneck back in 2006. His merge estimates tended to be things
> like "two months":
>
> http://lists.uclibc.org/pipermail/uclibc/2006-March/035793.html
>
> Five months later, Peter Mazinger beat some activity out of him:
>
> http://lists.uclibc.org/pipermail/uclibc/2006-August/016213.html
> http://lists.uclibc.org/pipermail/uclibc/2006-August/036995.html
> http://lists.uclibc.org/pipermail/uclibc/2006-August/037042.html
> http://lists.uclibc.org/pipermail/uclibc/2006-August/037121.html
>
> And so it continued on in 2007, where he was "a little behind doing customer
> releases":
>
> http://lists.uclibc.org/pipermail/uclibc/2007-May/038742.html
> http://lists.uclibc.org/pipermail/uclibc/2007-August/039210.html
>
> Of course I started complaining about lack of releases and questioning the
> nptl branch, yet again. Of course there were big long threads...
>
> http://lists.uclibc.org/pipermail/uclibc/2007-September/039215.html
> http://lists.uclibc.org/pipermail/uclibc/2007-September/039236.html
>
> Just like a year later: big long threads:
> http://lists.uclibc.org/pipermail/uclibc/2008-September/019976.html
>
> Anyway, at some point sjhill either threw in the towel or stopped responding,
> and Carmelo stepped up to do the merge, so he became the one and only person
> trying to merge the three branches, and thus the bottleneck:
>
> http://lists.uclibc.org/pipermail/uclibc/2008-April/019260.html
>
> And he remained the bottleneck for a while:
>
> http://lists.uclibc.org/pipermail/uclibc/2008-April/040090.html
> http://lists.busybox.net/pipermail/uclibc/2009-February/041949.html
> http://lists.uclibc.org/pipermail/uclibc/2009-June/042553.html
>
> This message is particularly amusing in retrospect:
>
> http://lists.uclibc.org/pipermail/uclibc/2008-April/019260.html
>
> He was the guy who just declared this problem no longer interesting.
>
> I've never understood why it's a separate branch:
>
> http://lists.uclibc.org/pipermail/uclibc/2008-December/041670.html
>
> Why we can't just check in the three implementations into -dev and merge them
> in situ. Put the code into the tree and let the uClibc development community
> have at.
>
> This is especially crazy since NPTL support for uClibc has been implemented
> from scratch at least three different tiimes. Sjhill did one for mips:
>
> http://kernel.org/doc/ols/2006/ols2006v1-pages-409-420.pdf
> http://kernel.org/doc/ols/2006/slides/sjh-ols-2006-presentation.odp
>
> Carmelo did one for sh4:
>
> http://lists.uclibc.org/pipermail/uclibc/2007-August/039207.html
>
> And of course codesourcery did its own from scratch for arm, and maintained it
> while while trying to get it merged:
> http://lists.uclibc.org/pipermail/uclibc/2006-September/037393.html
> http://lists.uclibc.org/pipermail/uclibc/2009-January/041779.html
>
> In the amount of time that's been wasted on the bottleneck-based merge
> approach in a separate -dev tree, NPTL could have been implemented for every
> single supported target about three times over.
>
> Meanwhile, the "don't break -dev by dumping nptl into it" approach has meant
> that we nobody's interested in testing -dev and nobody's interested in cutting
> releases from -dev, so stability of -dev and development speed in -dev are
> both much much slower than if the nptl patches had just been merged back in
> 2006.
>
> Instead, like the proverbial cutting wedge whose edge splits into two points,
> foreward progress goes to zero.
>
>> Regards,
>
> Rob
More information about the uClibc
mailing list