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 Sun Aug 01 2010 - 13:35:56 CEST
This archive was generated by hypermail 2.2.0 : Sun Aug 01 2010 - 13:48:01 CEST