Hello Matthias, Matthias Brugger <matthias.bgg@googlemail.com> writes:
I had a look in the unistd.h file I realized that system call numbers differ widely from other architectures (I had a look at arm and x86). Are the system call numbers platform specific.
Yes, system call numbers are platform-specific. They can even be different for very similar architectures (example: i386 and amd64). This should not usually be a problem: if you need to use system call numbers directly, use the __NR_* macros from the kernel headers for your system. Also, the calling convention for syscalls varies from one platform to another. Example: ARM and MIPS use processor registers to pass syscall arguments, while x86/amd64 use a combination of registers and arguments passed on the stack...
[...] As far as I understand, the system calls are "wrapped" in libc. So I wonder if [g,e,uC]libc uses a different system call number each architecture. A look in the source of uClibc didn't helped me to clear my doubts.
The interface with the kernel is always the same, no matter which particular libc implementation you use. So it does not matter if you use uClibc, glibc, eglibc, musl, newlib or any other libc, the numbers of syscalls and the way they have to be called from user space *for a given architecture* are always the same. The functions in the libc wrap syscalls and augment them: handling the "errno" variable, doing checks on arguments, etc.
If not all system calls are implemented for avr32: - is there a problem at all, or does libc implementation take care of not implemented system calls?
Some libc functions can be implemented using different syscalls. For example, the accept() function for sockets can be implemented in terms of the "accept4" syscall or the "accept": a typical libc implementation would check at which of both are available, and decide which exact syscall to use. Functions that do need a certain syscall and cannot be implemented in terms of other, indeed require those to be available - or the function will not work, Hope this helps clarifying a bit. Br. -- Adrian Perez <aperez@igalia.com> - Sent from my toaster Igalia - Free Software Engineering