[lkml]   [2001]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread

I have a question. Some architectures have "system calls"
implemented as library calls (calls that are "system calls" on ia32)
For example, the expectation on 'arm', seems to be that sys_sync
is in a library. On alpha, sys_open appears to be in a library.
Is this correct?

Is it the expectation that the library that handles this
is the 'glibc' for that platform or is there a special "kernel.lib"
that goes with each platform?

Is there 1 library that I need to link my apps with to
get the 'externs' referenced in "unistd.h"?

The reason I ask is that in ia64 the 'syscall' call
isn't done with inline assembler but is itself an 'extern' call.
This implies that you can't do system calls directly w/o some
support library.

The implication of this is that developers working on
platform independent system calls and library functions, for
example, extended attributes, audit or MAC, can't provide
platform independent patches w/o also providing their own
syscall implementation for ia64.

This came up as a problem when we wanted to provide a
a new piece of code but found it wouldn't link on some distributions.
In inquiry there seems to be some confusion regarding who is responsible
for providing this the code/library to satisfy this 'unistd.h' extern.

Should something so basic as the 'syscall' interface be provided
in the kernel sources, perhaps as a kernel-provided 'lib', or is
it expected it will be provided by someone else or is it expected
that each developer should provide their own syscall implementation for

The above thoughts and | They may have nothing to do with
writings are my own. | the opinions of my employer. :-)
L A Walsh | Trust Technology, Core Linux, SGI | Voice: (650) 933-5338
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.070 / U:3.816 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site