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