Using sysarch specific syscalls in assembly?

Robert Watson rwatson at FreeBSD.org
Tue Aug 9 09:13:48 GMT 2005


On Mon, 8 Aug 2005, ari edelkind wrote:

> On 8/8/2005, "alexander" <arundel at h3c.de> wrote:
>
> [...]
>> i386_set_ioperm(2) states that this procedure is a system call. So it should be
>> easily accessable through assembly language and it's specific syscall id.
>> Unfortunately I wasn't able to find the syscall id in any of the
>> syscalls.master files that are part of the source tree.
>>
>> <machine/sysarch.h> states that this is a sysarch specific syscall for i386
>> (hence the i386_*). The following definitions are being made:
>>
>> #define I386_GET_IOPERM 3
>> #define I386_SET_IOPERM 4
>>
>> These syscall numbers however are already taken by read(2) and 
>> write(2). So how can I make use of these i386 specific syscalls? Is it 
>> even possible?
>
> If you're unsure of how a function is called, you can always check the C 
> library, under 'src/lib/libc/'.  I won't repeat john baldwin's answer, 
> but it's exactly what you'd find there.
>
> That said, C library calls are no more difficult to perform from 
> assembly language than system calls, so long as you're willing to link 
> in the standard C library.  If you're trying to be more portable, then 
> unless you have specific reasons for not doing so, perhaps it's 
> something you'd like to consider.

In general, it is much preferable that applications link against libc to 
get the system call stubs than that they directly invoke system calls. 
That way, if compatibility interfaces are introduced, etc, the application 
will continue to function.  For example, there was at one point a 
migration away from explicit system calls to set certain kernel 
parameters, such as hostname and domainname, towards using sysctl, with 
the system calls being marked obsolete.  The C library still provides a 
sethostname() interface, which is actually a wrapper in user space around 
sysctl().  So invoking the C function provided by libc for a system call 
will generally be preferred, even if the originating code is assembly.

Robert N M Watson


More information about the freebsd-hackers mailing list