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: Urs Thuermann <urs at isnogud dot escape dot de>
- Subject: Re: system call stubs in glibc
- From: Andreas Jaeger <aj at suse dot de>
- Date: Sat, 11 Aug 2001 19:24:40 +0200
- Cc: glibc-linux at ricardo dot ecn dot wfu dot edu
- References: <m2bslmlgyf.fsf@isnogud.escape.de>
- 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)?
glibc reads <asm/unistd.h> and generates syscalls from this. This is
a pretty complicated process. To understand what's going check how
time is build now on your system.
> 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()?
What you need to do is:
- remove them from asm/unistd.h
- build a new glibc
- install the new glibc and the new kernel
i386/Linux might use sysdeps/unix/sysv/i386/time.S, check that instead
sysdeps/unix/time.c is used for compilation of time.os.
Note that the old glibc will not work with the new kernel.
Andreas
--
Andreas Jaeger
SuSE Labs aj@suse.de
private aj@arthur.inka.de
http://www.suse.de/~aj