unistd.h and 'extern's and 'syscall' "standard(?)"
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
Signature · 4 lines
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 [email protected] | Voice: (650) 933-5338
LA Walsh <[email protected]> writes:
|> 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.
Don't use kernel headers in user programs. Just use syscall(3).
Andreas.
Signature · 5 lines
Andreas Schwab "And now for something SuSE Labs completely different." [email protected] SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
Quoted 3 lines · Andreas Schwab
Don't use kernel headers in user programs. Just use syscall(3).
Andreas.
---
I'm on a SuSE71 system and have all the manpages installed:
law> man syscall
No manual entry for syscall
The problem is not so much for user programs as library
writers that write support libraries for kernel calls. For example there is libcap to implement posix capabilities on top of the kernel call. We have a libaudit to implement posix-auditing on top a a few kernel calls. It's the "system" library to system-call interface that's the problem, mainly. On ia64, it doesn't seem like there is a reliable, cross-distro, cross architecture way of interfacing to the kernel.
In saying "use syscall(3)" (which is undocumented on
my SuSE system, and on a RH61 sytem), implies it is in some library. I've heard rumors that the call isn't present in RH distros and they claim its because it's not exported from glibc. Then I heard glibc said it wasn't their intention to export it. (This is all 2nd hand, so forgive me if I have parties or details confused or mis-stated). It seems like kernel source points to an external source, Vender points at glibc, glibc says not their intention. Meanwhile, an important bit of kernel functionality --
being able to use syscall0, syscall1, syscall2...etc, ends up missing for those wanting to construct libraries on top of the kernel.
I end up being rather perplexed about the correct course
of action to take. Seeing as you work for suse, would you know where this 'syscall(3)' interface should be documented? Is it supposed to be present in all distro's?
Thanks,
-linda
Signature · 4 lines
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 [email protected] | Voice: (650) 933-5338
Quoted 3 lines
of action to take. Seeing as you work for suse, would you know where this 'syscall(3)' interface should be documented? Is it supposed to be present in all distro's?
It's documented in the glibc manual. Yes, it should be present in all glibc based distributions.
p.
And furthermore, it's been around in Unix and unix-like systems for a very long time. Sounds like the lack of man page is an oversight. Anybody want to write one ?
Tim
Quoted 15 lines · Philip Blundell
Quoted 3 lines
of action to take. Seeing as you work for suse, would you know where this 'syscall(3)' interface should be documented? Is it supposed to be present in all distro's?
It's documented in the glibc manual. Yes, it should be present in all glibc based distributions.
p.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 4 lines
Tim Wright - [email protected] or [email protected] or [email protected] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI