This is the mail archive of the
glibc-linux@ricardo.ecn.wfu.edu
mailing list for the glibc project.
Re: system call stubs in glibc
- To: glibc-linux at ricardo dot ecn dot wfu dot edu
- Subject: Re: system call stubs in glibc
- From: Andreas Schwab <schwab at suse dot de>
- Date: 11 Aug 2001 19:32:50 +0200
- References: <m2bslmlgyf.fsf@isnogud.escape.de.suse.lists.glibc-linux>
- Reply-To: glibc-linux at ricardo dot ecn dot wfu dot edu
Urs Thuermann <urs@isnogud.escape.de> writes:
|> There are system calls which exist in the Linux kernel on some
|> architectures but not others. For example time(2) and stime(2) exist
|> on all architectures but alpha and ia64. I assume these are
|> implemented by glibc using gettimeofday(2) and settimeofday(2) on
|> alpha and ia64, correct?
|>
|> If so, how does glibc know, which system calls on which architectures
|> exist, and when to implement them using other calls? Is this
|> configured in some architecture-depend config file or does glibc check
|> itself for the availability of system calls like time(2) and stime(2)?
There are various files named syscalls.list under the sysdeps/unix tree.
They define the syscalls that _may_ be present. The make-syscalls.sh
script goes through them and looks to see if the syscalls are actually
present and generates the file sysd-syscalls in the build directory
according to this information. For the functions that are implemented as
syscalls there are usually fallback implementations,
eg. sysdeps/unix/time.c and sysdeps/unix/stime.c. The build process
automatically picks them up when a syscall implementation is not
available. Note that the fallbacks in sysdeps/generic are often only
stubs that always fail.
|> The reason I ask is, I'd like to know, if I would remove time() and
|> stime() from the kernel on my i386/Linux, would glibc, when configured
|> and compiled again running on that modified kernel, use
|> get/settimeofday() or would it fail when someone uses time() or
|> stime()?
This should work as expected. You just have to make sure that __NR_time
and __NR_stime are not defined in <asm/unistd.h>.
Andeas.
--
Andreas Schwab "And now for something
SuSE Labs completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5