Re: [dev] How about sta.li ? - libc tangent

> Perhaps it's a mad thought, but what about building a p9p-alike on top of a modified, ported Plan 9 libc? I expect most of the system calls would pose no more trouble than in p9p. It's work to be done over again, borrowing methods from p9p, but some parts will actually be easier. For example, the Linux kernel's clone system call is far closer to plan 9's fork() than posix threads clone() interface is.

This is quite similar to what the Go runtime itself does: it bypasses
libc on all systems and instead has a portability layer that calls the
relevant syscalls for each supported platform.

It makes portability harder, but this days when only linux and perhaps
OS X and some BSD matter, this is not a big deal (even the current p9p
way of doing things has not helped portability to systems like
solaris, and Windows, while Go has already been ported to Windows).

On the other hand the Go people have found that completely bypassing
the libc can be a pain because one has to re-implement all the
braindead functionality of things like the resolver (including parsing
of /etc/hosts, and what if the system is configured to use ldap, or
god knows what?). But not supporting such retarded setups might be
also considered a feature...

uriel

uriel

On Sun, Aug 1, 2010 at 1:35 PM, Ethan Grammatikidis <eekee57_AT_fastmail.fm> wrote:
>
> On 1 Aug 2010, at 8:43, pancake wrote:
>
>> I want to say that in latest glibc (see archlinux) many 9base programs
>> cant be executed because of being static.
>
> I sent the other mail off & then I thought, are you talking about finding a
> sane libc for any linux, not just sta.li? I've been thinking about it
> lately, needing to avoid glibc, OS X's libc, and gcc for various reasons
> including the dynamic linking issue. There are C compilers with the Go
> distribution which will produce Linux and OS X executables, but no libc, and
> that started me thinking, specifically with the goal of getting a statically
> linked p9p on one machine and a completely glibc-free p9p/9base and inferno
> on another.
>
> Perhaps it's a mad thought, but what about building a p9p-alike on top of a
> modified, ported Plan 9 libc? I expect most of the system calls would pose
> no more trouble than in p9p. It's work to be done over again, borrowing
> methods from p9p, but some parts will actually be easier. For example, the
> Linux kernel's clone system call is far closer to plan 9's fork() than posix
> threads clone() interface is.
>
> I figure it could go one of two ways. One way some functionality would be
> disabled, giving a very p9p-like result. I called this 9libc. The other way,
> a 9p multiplexer server could be made. Along with support servers this could
> ultimately give a very complete Plan 9 experience without any of the
> performance issues of virtualisation or the other issues of 9vx. I called
> this Under9. Under9 is distinct from Glendix in that Glendix is
> Linux-specific, which doesn't make me happy and appears make more work for
> the maintainers. Under9 ought to work with any kernel the libc has been
> ported to. Also, Under9 need not try to load Plan 9 format binaries if that
> turns out to be inefficient.
>
> So I have more project names than code, here. I wasn't planning on bringing
> up these ideas until I at least had a good idea of what would be involved in
> porting the libc, but the topic kinda came up.
>
>
Received on Mon Aug 02 2010 - 16:47:29 CEST