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
[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.
--
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
Andreas Schwab wrote:
> 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
--
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
>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
On Sun, Apr 01, 2001 at 09:38:24PM +0100, Philip Blundell wrote:
> >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/
--
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