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.
