system call numbers
Hi all, I'm looking into the avr32 architecture implementation, as compiling the kernel gives you several warnings about system calls which are missing. 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. 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. 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? - if I want to add a system call, what are the steps needed? Best regards, Matthias
Hi Matthias, El Thu, Nov 22, 2012 at 09:44:37AM +0100 Matthias Brugger ha dit:
I'm looking into the avr32 architecture implementation, as compiling the kernel gives you several warnings about system calls which are missing.
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. 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.
yes, the system call numbers are architecture specific Documentation/ABI/stable/syscalls: Note that this interface is different for every architecture that Linux supports. Please see the architecture-specific documentation for details on the syscall numbers that are to be mapped to each syscall
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? - if I want to add a system call, what are the steps needed?
there are several sources out there explaining this, one is http://www.ibm.com/developerworks/library/l-system-calls/ best regards -- Matthias Kaehlcke Embedded Linux Developer Amsterdam There is nothing so useless as doing efficiently that which should not be done at all (Peter Drucker) .''`. using free software / Debian GNU/Linux | http://debian.org : :' : `. `'` gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
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
participants (3)
-
Adrian Perez de Castro -
Matthias Brugger -
Matthias Kaehlcke