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:

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

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,

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...

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.

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 <[email protected]> - Sent from my toaster
Igalia - Free Software Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20121122/2a37882f/attachment-0001.bin