[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56DB6095.4060204@FreeBSD.org>
Date: Sat, 5 Mar 2016 17:41:25 -0500
From: Pedro Giffuni <pfg@...eBSD.org>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: FreeBSD's Google Summer of Code 2016
Hello Rich;
On 03/05/16 16:25, Rich Felker wrote:
> On Sat, Mar 05, 2016 at 03:11:28PM -0500, Pedro Giffuni wrote:
>> Hello;
>>
>> Just thought I'd point this out in case there are students looking
>> for a summer project (paid by Google):
>>
>> In FreeBSD we are always open to alternatives. For this GSoC we
>> would consider someone willing to work on a musl port.
>>
>> https://wiki.freebsd.org/SummerOfCodeIdeas#Port_musl_libc
>>
>> For such a port you obviously have to have love for the C language
>> and specific skills (version control, knowledge of the build system,
>> UNIX/syscall knowledge), but I think it may very well be a fun
>> project for the right person.
>>
>> We generally ask for very detailed proposals and it certainly
>> would help if you get to try FreeBSD before considering a
>> proposal, The process is competitive so we are interested
>> in your background.
>>
>> We are aware musl is centered around linux but just as someone
>> managed to port glibc to FreeBSD we think it should be possible
>> to make a port clean port of musl. This project would only make
>> sense if the code is upstreamed, so at some stage we would also
>> appreciate support from musl developers.
>>
>> For applying you should follow the standard procedure with Google.
>> https://summerofcode.withgoogle.com/how-it-works/
>
> Nice!
>
> From our side (musl), the biggest obstacle when people have looked at
> doing such a port in the past seems to be missing syscalls, especially
> futex and related functionality. For that reason, up til now,
> FreeBSD's Linux syscall layer has seemed more functional, and a better
> basis for musl-on-FreeBSD, than the native syscall layer. I think a
> viable proposal needs a solution to this problem on the kernel side --
> perhaps exposing some of these syscalls that are Linux-emulation-only
> now in the native API?
>
First of all, great to hear there is interest on the musl side too.
I think the biggest precedent of porting linux-oriented C libraries
came from Debian's kFreeBSD. We accomodated a little by for them
by defining __FreeBSD_kernel__ in sys/param.h.
While using the optional linux-abi futex in FreeBSD could be an option,
it is not really the cleanest option. The Debian guys did a port of
NPTL using regular pthreads:
http://thread.gmane.org/gmane.linux.debian.ports.bsd/11702
I am certain this will require more research but it would be useful
for other ports as well.
Pedro.
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.
