Messages in this thread | | | Date | Sun, 01 Apr 2001 09:56:31 -0700 | From | LA Walsh <> |
| |
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 ia64?
Thanks, -linda -- 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 law@sgi.com | Voice: (650) 933-5338 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |