Re: unistd.h and 'extern's and 'syscall' "standard(?)"

[LA Walsh <law@sgi.com>]

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
law@sgi.com                      | Voice: (650) 933-5338