Porting uclibc to the other OS

Alfeiks Kaänoken madtirra at jarios.org
Wed Jan 26 10:02:05 UTC 2011


Hi list,
I spent some time with investigation to choose 
libC for the Jari OS platform (it's a microkernel, 
unix-like OS for specific area).
I found uclibc is better one from the existing ones 
(glibc is too large, newlib is very minimalistic).
My first review of the existing sysdeps and other source code 
shows me that there are many linux-specific code (yes, 
I mean linux specific code that resides within non-os specific 
code).
btw, the main difference with linux (or other monolithic OSes) is 
many OS functions (open() for example) aren't syscalls - it's 
RPC functions (yes, actually it will be a syscall that call IPC 
function to send an RPC message). In this case I need to 
find a better way to port it (i.e. without heavy modifications to 
keep uclibc sources tree more closely to the upstream one).
Could you advice me something ?

I guess that the following information will be useful for it:
 - RPC functions generates via IDL
 - POSIX threads functions are syscalls
 - Jari OS is unix-like (no, I'm not using a crack)
 - We don't have brk/sbrk functions (only mmap (it's a syscall, 
but to map file/device/dma there are some tricks exist))
 - We have an existing libc (own library, most of functions 
just taken from uclibc/newlib/glibc), but it's very ugly to 
continue extending this one
 - binutils/gcc already ported
 - We don't have linux-specific features (like readahead kernel hint)

Thanks,



More information about the uClibc mailing list