[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD-J=zYkxG0hDt_1YqKEHqE4crpUnm70_1PJn+khZGLQJPYHeQ@mail.gmail.com>
Date: Mon, 21 Jul 2014 14:29:59 +0400
From: Glauber Costa <glommer@...udius-systems.com>
To: Glauber Costa <glommer@...udius-systems.com>, musl@...ts.openwall.com
Subject: Re: [PATCH] implement glibc's glob_pattern_p
Hi,
On Mon, Jul 21, 2014 at 12:36 AM, Szabolcs Nagy <nsz@...t70.net> wrote:
> * Glauber Costa <glommer@...udius-systems.com> [2014-07-17 13:12:55
> +0400]:
> ...
>
> btw do you happen to know anything about the osv project
> developed by cloudius-systems?
>
Since we have no other projects than OSv at the moment, yes, I do know
about it =)
>
> they seem to have copied a lot of code from musl, but
> never said a word about it here.. would be nice to know
> where they are going with it.. or why they decided to
> use musl in the first place
>
I am sorry about that! The decision to use musl was a very early
one, before I joined the company (even though I am employee # 4 =p)
As far as I know, it was motivated by both the license, and the coverage set
which was quite good, with good code quality. It also fits very well our
goal
of being lightweight and lean.
>From my perspective, it would be good for us to be just able to import
upstream
musl without having it in our tree - exactly for the reasons you point
below, of bugfixes.
But we don't really use all of it, some files were converted to C++, and
other small
changes to fit our environment, etc. Part of the reason we don't use musl
in its
entirety, is that our core kernel provides the linux-compatible apis
directly, without
a wrapper being needed. We also don't call __syscall, etc.
It would definitely be good if musl had a build environment that allowed us
to build
just part of it and be more flexible with what we include in the image,
etc. But it is
not our priority to work on it right now - we're just too few people, with
too big of a
task =(
>
> and looking at the libc/ code in osv, they don't really
> back port bug fixes so there are some old musl bugs there..
>
Yes, we don't have the capacity to track it, that's why I believe
eventually we will have
to work towards being able to consume musl as a totally external entity,
rather than
importing code in our libc directory - if the changes needed for that are
acceptable
for you guys, of course. If you have from the top of your head the hashes
for some
of those bugfixes you mention, that would of course be a great service =)
What I can and happily will do, for the moment, is to send you back
whatever changes
we make on our side, like this one patch here.
Thanks again
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
