Where to Find Linux API Information?

[Ben Pfaff]

I'll be using gcc under Red Hat Enterprise Linux.

Where do I find information about the low-level calls to the operating
system from compiled 'C'?

Your question is outside the domain of comp.lang.c, which discusses
only the standard C programming language, including the standard C
library. This is a remarkably narrow topic compared to what many
people expect.

For your convenience, the list below contains topics that are not
on-topic for comp.lang.c, and suggests newsgroups for you to explore
if you have questions about these topics. Please do observe proper
netiquette before posting to any of these newsgroups. In particular,
you should read the group's charter and FAQ, if any (FAQs are
available from www.faqs.org and other sources). If those fail to
answer your question then you should browse through at least two weeks
of recent articles to make sure that your question has not already
been answered.

* OS-specific questions, such as how to clear the screen,
access the network, list the files in a directory, or read
"piped" output from a subprocess. These questions should be
directed to OS-specific newsgroups, such as
comp.os.ms-windows.programmer.misc, comp.unix.programmer, or
comp.os.linux.development.apps.

* Compiler-specific questions, such as installation issues,
locations of header files, configuring your C development
environment, or choosing or managing profiling tools,
debuggers, or code coverage tools. Ask about these in
compiler-specific newsgroups, such as gnu.gcc.help or
comp.os.ms-windows.programmer.misc. Questions about writing
compilers are appropriate in comp.compilers.

* Library-specific questions, such as how to use GLib, Kazlib,
libavl, libsndfile, GMP, GNU GSL, djbfft, CLAPACK, CBLAS,
libtomcrypt, etc. Ask about these in library-specific
newsgroups or mailing lists.

* Processor-specific questions, such as questions about
assembly and machine code. x86 questions are appropriate in
comp.lang.asm.x86, embedded system processor questions may
be appropriate in comp.arch.embedded.

* ABI-specific questions, such as how to interface assembly
code to C. These questions are both processor- and
OS-specific and should typically be asked in OS-specific
newsgroups.

* Algorithms, except questions about C implementations of
algorithms. "How do I implement algorithm X in C?" is not a
question about a C implementation of an algorithm, it is a
request for source code. Newsgroups comp.programming and
comp.theory may be appropriate.

* Making C interoperate with other languages. C has no
facilities for such interoperation. These questions should
be directed to system- or compiler-specific newsgroups. C++
has features for interoperating with C, so consider
comp.lang.c++ for such questions.

* The C standard, as opposed to standard C. Questions about
the C standard are best asked in comp.std.c.

* C++. Please do not post or cross-post questions about C++
to comp.lang.c. Ask C++ questions in C++ newsgroups, such
as comp.lang.c++ or comp.lang.c++.moderated.

* Test posts. Please test in a newsgroup meant for testing,
such as alt.test.

news.groups.questions is a good place to ask about the appropriate
newsgroup for a given topic.

 

[David T. Ashley]

I'll be using gcc under Red Hat Enterprise Linux.

Where do I find information about the low-level calls to the operating
system from compiled 'C'?

For example, if I want to cause a process to sleep, or look at the
permissions of a file ... where is this written down?

Thanks, Dave.

 

[Spiros Bousbouras]

I'll be using gcc under Red Hat Enterprise Linux.

Where do I find information about the low-level calls to the operating
system from compiled 'C'?

For example, if I want to cause a process to sleep, or look at the
permissions of a file ... where is this written down?

This is out of topic here.

As a short answer, "Advanced programming in the Unix
environment" by Stevens and Rago is an excellent resource.

For further questions on this topic try comp.unix.programmer

 

[Tommy Reynolds]

Where do I find information about the low-level calls to the operating
system from compiled 'C'?

The system calls are documented in section 2 of the online manual. If you
know the name of the system call, you can see it by using this
command:

$ man 2 name

where 'name' is replaced by the system call name. For example,

$ man 2 read

for the read(2) system call. Notice the practice of using the manual
section number (2) to disambiguate from the C runtime library's
read(3) routine. (Library routines go into section 3 of the manual).

To see all available system calls, you can do this:

$ cd /usr/share/man/man2
$ for x in *gz
do
zcat $x | nroff -man | less
done

and reading, and reading, and reading...

 

[Keith Thompson]

The system calls are documented in section 2 of the online manual.

[snip]

The distinction between system calls and calls to library functions is
usually irrelevant, for reasons that are best discussed in a newsgroup
other than comp.lang.c.

This is cross-posted to alt.os.linux; I've redirected followups there.

 

[ray]

The system calls are documented in section 2 of the online manual. If you
know the name of the system call, you can see it by using this
command:

$ man 2 name

where 'name' is replaced by the system call name. For example,

$ man 2 read

for the read(2) system call. Notice the practice of using the manual
section number (2) to disambiguate from the C runtime library's
read(3) routine. (Library routines go into section 3 of the manual).

To see all available system calls, you can do this:

$ cd /usr/share/man/man2
$ for x in *gz
do
zcat $x | nroff -man | less
done

and reading, and reading, and reading...

Much simpler to use xman.

 

[CBFalconer]

I'll be using gcc under Red Hat Enterprise Linux.

Where do I find information about the low-level calls to the
operating system from compiled 'C'?

For example, if I want to cause a process to sleep, or look at
the permissions of a file ... where is this written down?

In the documentation for your system. Nothing to do with C.

 

[David T. Ashley]

In the documentation for your system. Nothing to do with C.

Yes and no. I've never figured out the exact relationship between the C
library and the underlying system calls. I figured this would be a good
place to start with the questions.

For example, "man 3 sleep" gives:

sleep() may be implemented using SIGALRM; mixing calls to alarm() and
sleep() is a bad idea.

I'm not really sure what is going on under the hood there, or why the word
"may" was chosen.

And you cited "documentation for your system". That is what ... I'm trying
to find.

 

[Keith Thompson]

Yes and no. I've never figured out the exact relationship between the C
library and the underlying system calls. I figured this would be a good
place to start with the questions.

For example, "man 3 sleep" gives:

sleep() may be implemented using SIGALRM; mixing calls to alarm() and
sleep() is a bad idea.

I'm not really sure what is going on under the hood there, or why the word
"may" was chosen.

And you cited "documentation for your system". That is what ... I'm trying
to find.

What we discuss here is the standard C programming language, as
defined by the ISO standard (either the 1990 or 1999 version). If
you're sufficiently interested, the latest draft of the standard is
n1124.pdf; it's not light reading, but it's a good way to find out
what's defined by the standard and what isn't.

<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c> is a good
introduction to the newsgroup, but I can't reach the site at the
moment.

The C standard makes no distinction between library calls and system
calls. sleep() and alarm() in particular are not standard C
functions. For more information, comp.unix.programmer or one of the
Linux groups is a better place to ask than this is.

 

[Davorin Vlahovic]

I'll be using gcc under Red Hat Enterprise Linux.

Where do I find information about the low-level calls to the operating
system from compiled 'C'?

For example, if I want to cause a process to sleep, or look at the
permissions of a file ... where is this written down?

Get the glibc-doc package for whatever distro you're using and you
should find most of the stuff in there.

So, if you're running Debian, Ubuntu, Knoppix or something with apt,
type

apt-get install glibc-doc

and after the installation the files should be in
/usr/share/doc/glibc-doc.

Also, I reccomend for you to get ahold of "Art of Unix programming"
(Eric Steven Raymond) and especially "Advanced Linux programming"
(Mitchell-Oldham-Samuel).

 

[birre]

I'll be using gcc under Red Hat Enterprise Linux.

Where do I find information about the low-level calls to the operating
system from compiled 'C'?

For example, if I want to cause a process to sleep, or look at the
permissions of a file ... where is this written down?

Thanks, Dave.

The manuals are in different sections:

man man
1 Executable programs or shell commands
2 System calls (functions provided by the kernel)
3 Library calls (functions within program libraries)
4 Special files (usually found in /dev)
5 File formats and conventions eg /etc/passwd
6 Games
7 Miscellaneous (including macro packages and conven-
tions), e.g. man(7), groff(7)
8 System administration commands (usually only for root)
9 Kernel routines [Non standard]

If you do:
apropos sleep , you will see available manuals in different sections.

sleep (3) - Sleep for the specified number of seconds
clock_nanosleep (3p) - high resolution sleep with specifiable clock (ADVANCED
REALTIME)
sleep (1) - delay for a specified amount of time
ata_busy_sleep (9) - sleep until BSY clears, or timeout
sleep (3p) - suspend execution for an interval of time
Usleep (1) [usleep] - sleep for the specified number of microseconds
Time::HiRes (3pm) - High resolution alarm, sleep, gettimeofday, interval timers
nanosleep (2) - pause execution for a specified time
usleep (3p) - suspend execution for an interval
Tcl_Sleep (3) - delay execution for a given number of milliseconds
nanosleep (3p) - high resolution sleep (REALTIME)
sleep (1p) - suspend execution for an interval
usleep (3) - suspend execution for microsecond intervals
msleep_interruptible (9) - sleep waiting for signals
usleep (1) - sleep for the specified number of microseconds
schedule_timeout (9) - sleep until timeout
msleep (9) - sleep safely even with waitqueue interruptions

/birre

 

[Tom St Denis]

For example, "man 3 sleep" gives:

sleep() may be implemented using SIGALRM; mixing calls to alarm() and
sleep() is a bad idea.

I'm not really sure what is going on under the hood there, or why the word
"may" was chosen.

Because different OSes may have a different way of doing timers.

You sir, need to take a comp.sci degree, in particular, study hard
during your operating systems classes.

Tom

 

[Random832]

Because different OSes may have a different way of doing timers.

Or the library may operate differently for short sleep()s vs long ones.

Or odd ones vs even ones, who knows. Short vs long at least makes some
sense.

 

[Stephen Sprunk]

Yes and no. I've never figured out the exact relationship between the
C library and the underlying system calls. I figured this would be a
good place to start with the questions.

For example, "man 3 sleep" gives:

sleep() may be implemented using SIGALRM; mixing calls to alarm()
and sleep() is a bad idea.

I'm not really sure what is going on under the hood there, or why the
word "may" was chosen.

And you cited "documentation for your system". That is what ... I'm
trying to find.

<OT>
"man" _is_ the documentation for your system. The actual C and POSIX
standards may help, but your system provides a lot of things that aren't
in either.

The difference between library functions and system calls is that the
syscalls are direct access to the kernel, whereas library functions are
not _directly_ turned into system calls.

This gets confusing only because libc provies a convenient C interface
to the syscalls, i.e. the stuff in section 2 of the manual. The stuff
in section 3 of the manual either is built on top of the syscalls, e.g.
fread(3) probably calls read(2), or is handled entirely in userspace,
e.g. qsort(3) doesn't need any help from the kernel.

If you only use functions from section 3, your code has a chance of
being portable to non-POSIX systems, though there's still a lot of
(non-C-Standard) stuff in there that might not happen to exist on other
systems but you could either work around or reimplement yourself when
porting. If you stray into section 2, you'll definitely be limited to
POSIX systems or possibly even the particular OS you're on.
</OT>

S

 

[Tom St Denis]

Or the library may operate differently for short sleep()s vs long ones.

Or odd ones vs even ones, who knows. Short vs long at least makes some
sense.

Well one may use SIGALRM and another may have SIGTIMR, and another may
invoke a syscall, and another may ....

Different OSes pass messages in different ways. *That's* why you don't
mix alarm with sleep, because you don't know if your platform uses it
(which is valid).

Tom

 

[rhle.freak]

I'll be using gcc under Red Hat Enterprise Linux.

Where do I find information about the low-level calls to the operating
system from compiled 'C'?

For example, if I want to cause a process to sleep, or look at the
permissions of a file ... where is this written down?

Thanks, Dave.

i guess this might help..
http://www.cs.cf.ac.uk/Dave/C/