system call numbers

[Adrian Perez de Castro]

Hello Matthias,

Matthias Brugger <matthias.bgg at 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 at igalia.com> - 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