I am the maintainer of it, but unfortunately, even though my activity
is very low (being busy in many respects, family, job, German amateur
radio league, other opensource stuff as well), I don't know of anyone
being more active than me - even though the list of allowed committers
is quite a bit longer.
Thanks for getting back. No doubt avr-libc is deployed in an incredible quantity of devices these days, not the least of which is driven by it being the foundation for Arduino.
Judging by the mailing list archives, it seems there is quite a bit of pent-up demand for minor enhancements, but it does not look like the 2.0.0 version has been touched in a few years.
What is the route to becoming an allowed committer — if I or someone has time to help out with this?
Anyways — the thing that sparked this particularly inquiry is an idea for an enhancement which I will send to this list under separate cover. If it’s an idea worthy of consideration, I’ll submit a patch, in the hopes that it can become merged with upstream.
> On Jan 21, 2019, at 3:48 PM, Joerg Wunsch <[hidden email]> wrote:
> As Taavo Raykoff wrote:
>> Is there any active maintainer on avr-libc?
> Depends on your definition of "active".
> I am the maintainer of it, but unfortunately, even though my activity
> is very low (being busy in many respects, family, job, German amateur
> radio league, other opensource stuff as well), I don't know of anyone
> being more active than me - even though the list of allowed committers
> is quite a bit longer.
> cheers, Joerg .-.-. --... ...-- -.. . DL8DTL
> http://www.sax.de/~joerg/ > Never trust an operating system you don't have sources for. ;-)
> What is the route to becoming an allowed committer — if I or someone
> has time to help out with this?
Given the low activity of all existing committers (including me), I'd
say: enough dedication ...
Regarding your malloc stuff: there is a testsuite in the source
repository, glued around simulavr. It contains a number of regression
tests to make sure no older malloc bug has been re-introduced. It
would be really cool if you could see whether you can get that
testsuite to some life, and to test your patch.
Otherwise, I love the idea of allowing malloc() to become reentrant.
Another idea would be moving the existing malloc into a malloc_r()
implementation, with standard malloc() wrapping around it. That's
basically what newlib does for ARM-GCC.