Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword or section
Like this
12Activity

Table Of Contents

0 of .
Results for:
No results containing your search query
P. 1
Linux System Calls

Linux System Calls

Ratings:

4.5

(2)
|Views: 671 |Likes:
Published by PRADEEP_P
LINUX system calls
LINUX system calls

More info:

Published by: PRADEEP_P on Aug 04, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/06/2011

pdf

text

original

 
Linux System CallsReleased to the Public Domain by Randall HydePage 1
Linux System Calls for HLA Programmers
1Introduction
This document describes the interface between HLA and Linux via direct system calls. The HLA StandardLibrary provides a header file with a set of important constants, data types, and procedure prototypes that you can useto make Linux system calls. Unlike the "C Standard Library," the HLA-based systems calls add very little overheadto a system call (generally, they move parameters into registers and invoke Linux with very little other processing).Note that I have copied information from the Linux
man
pages into this document. So whatever copyright (copy-left) applies to that information applies here as well. As far as I am concerned, my work on this document is publicdomain, so this document inherits the Linux documentation copyright (I don’t know the details, but it’s probably the"Free Documentation" license; whatever it is, it applies equally here).Note that Linux
man
pages are known to contain some misinformation. That misinformation was copied straightthrough to this document. Of course, in a document of this size, there are probably some defects I’ve introduced aswell, so keep this in mind when using this document.
Disclaimer
: I would like to claim that every effort has been taken to ensure the accuracy of the material appearingwithin this document. That, however, would be a complete lie. In reality, I copied the man pages to this document andmake a bunch of quick changes for HLA/assembly programmers to their descriptions. Undoubtedly, this process hasintroduced additional defects into the descriptions. Therefore, if something doesn’t seem right or doesn’t seem towork properly, it’s probably due to an error in this documentation. Keep this in mind when using this document.Hopefully as time passes and this document matures, many of the defects will disappear. Also note that (as this wasbegin written) I have not had time to completely test every system call, constant, and wrapper function provided withHLA. If you’re having a problem with a system call, be sure to check out the HLA source code for the Linux wrapperfunctions and whatever constants and data types you’re using from the linux.hhf module.
1.1Direct System Calls from Assembly Language
To invoke a Linux system call (i.e., a Linux API call), you load parameters into various registers, load a systemcall opcode into the EAX register, and execute an INT($80) instruction. Linux returns results in the EAX registerand, possibly, via certain pass by reference parameters.The HLA "linux.hhf" header file contains constant declarations for most of the Linux system call opcodes. Theseconstants take the form "sys_
 function
" where
 function
represents a Linux system call name. For example, "sys_exit"is the symbolic name for the Linux "_exit" call (this constant just happens to have the value one).If you read the on-line documentation for the Linux system calls, you’ll find that the API calls are specified usinga "C" language syntax. However, it’s very easy to convert the C examples to assembly language. Just load the associ-ated system call constant into EAX and then load the 80x86 registers with the following values:1st parameter: EBX2nd parameter: ECX3rd parameter: EDX4th parameter: ESI5th parameter: EDICertain Linux 2.4 calls pass a sixth parameter in EBP. Calls compatible with earlier versions of the kernel pass six ormore parameters in a parameter block and pass the address of the parameter block in EBX (this change was probablymade in kernel 2.4 because someone noticed that an extra copy between kernel and user space was slowing downthose functions with exactly six parameters; who knows the real reason, though).As an example, consiider the Linux
exit
system call. This has a "C" prototype similar to the following:
void exit( int returnCode );
The assembly invocation of this function takes the following form:
 
Linux System CallsPage 2Version: 4/5/02Written by Randall Hyde
mov( sys_exit, eax );mov( returnCode, ebx );int( $80 );
As you can see, calls to Linux are very similar to BIOS or DOS calls on the PC (for those of you who arefamiliar with such system calls).While it is certainly possible for you to load the system call parameters directly into the 80x86 registers,load a system call "opcode" into EAX, and execute an INT($80) instruction directly, this is a lot of work if your program makes several Linux system calls. To make life easier for assembly programmers, the Linuxsystem call module provided with the HLA Standard Library provides
wrapper 
functions that make Linuxsystem calls a lot more convenient. These are functions that let you pass parameters on the stack (using theHLA high level procedure call syntax) which is much more convenient than loading the registers and execut-ing INT($80). For example, consider the following implementation of the "linux._exit" function the Linuxmodule provides:
procedure _exit( RtnCode: dword ); @nodisplay;begin _exit;mov( sys_exit, eax );mov( RtnCode, ebx );int( $80 );end _exit;
You can call this function using the HLA syntax:
linux._exit( returnValue );
As you can see, this is far more convenient to use than the INT($80) sequence given earlier. Furthermore,this calling sequence is very similar to the "C" syntax, so it should be very familiar to those reading Linuxdocumentation (which is based on "C").Your code would probably be slightly smaller and a tiny bit faster if you directly make the INT($80)calls.. However, since the transition from user space to kernel space is very expensive, the few extra cyclesneeded to pass the parameters on the stack to the HLA functions is nearly meaningless. In a typical (large)program, the memory savings would probably be measured in hundreds of bytes, if not less. So you’re notreally going to gain much by making the INT($80) calls. Since the HLA code is much more convenient touse, you really should call the Standard Library functions. For those who are concerned about inefficiencies,here’s what a typical HLA Standard Library Linux system call looks like. As you can see, there’s not muchto these functions. So you shouldn’t worry at all about efficiency loss.On occasion, certain Linux system calls become obsolete. Linux has maintained the calls for the olderfunctions for those programs that require the old semantics, while adding new API calls that support addi-tional features. A classic example is the LSEEK and LLSEEK functions. Originally, there was only LSEEK(that only supports two gigabyte file lengths). Linux added the LLSEEK function to allow access to largerfiles. Still, the old LSEEK function exists for code that was written prior to the development of the LLSEEKcall. So if you use the INT($80) mechanism to invoke Linux, you probably don’t have to worry too muchabout certain system calls disappearing on you.There is, however, a
big
 advantage to using the HLA wrapper functions. If you use the INT($80) call-ing mechanism and a system call becomes obsolete, your program will probably still work but it won’t beable to take advantage of the new Linux features within your program without rewriting the affectedINT($80) calls. On the other hand, if you call the HLA wrappers, this problem exists in only one place -- inthe HLA Standard Library wrapper functions. This means that whenever the Linux system calls change, youneed only modify the affected wrapper function (typically in one place), recompile the HLA StandardLibrary, recompile your applications, and you’re in business. This is
much
 easier than attempting to locateevery INT($80) call in your code and checking to see if you need to change it. Combined with the ease of calling the HLA wrapper functions, you should serious consider whether it’s worth it to call Linux viaINT($80). For this reason, the remainder of this document will assume that you’re using the HLA Linux
 
 Linux System CallsReleased to the Public Domain by Randall HydePage 3module to call the Linux APIs. If you choose to use the INT($80) calling mechanism instead, conversion is fairlytrivial (as noted above).
 1.2A Quick Note About Naming Conventions
 Most Linux documentation was written assuming that the reader would be calling Linux from a C/C++ program.While the HLA header files (and this document) attempt to stick as closely to the original Linux names as possible,there are a few areas where HLA names deviate from the C names. This can occur for any of three reasons:The C name conflicts with an HLA reserved word (e.g., "exit" becomes "_exit" because "exit" is anHLA reserved word).C uses different namespaces for structs and other objects and some Linux identifiers are the same forboth structs and variables (HLA doesn’t allow this).HLA uses case neutral identifiers, C uses case sensitive identifiers. Therefore, if two C identifiers arethe same except for alphabetic case, one of them must be changed when converting to HLA.Many Linux constant and macro declarations use the (stylistically dubious) convention of all uppercasecharacters. Since uppercase is hard to read, such identifiers have been converted to all lowercase in theHLA header files.
 1.3A Quick Note About Error Return Values
 C/C++ programmers probably expect Linux system calls to return -1 if an error occurs and then they expect tofind the actual error code in the
errno
 global variable. Assembly language calls to Linux return the error statusdirectly in the EAX register. Generally, if the return value is non-negative, this indicates success and the value is afunction result. If the return value from a Linux system call is negative, this usually indicates some sort of error.Therefore, an assembly language program should test the value in EAX upon return for negative/non-negative todetermine the error status.Linux system calls return a wide range of negative values indicating different error values. The "linux.hhf"header file defines a set of symbolic constants in the
errno
 namespace so you can use symbolic names rather than lit-eral constants. These names and values are identical to those found in standard Linux documentation with threeexceptions: (1) the HLA naming convention uses lower case for these identifiers rather than all uppercase letters; e.g.,
 EPERM
 is spelled
eperm
 . (2) Since the HLA names are all found in the
errno
 namespace, you refer to them using an"
 errno
 ." prefix, e.g., "
 errno.eperm
 " is the correct way to specify the "error, invalid permissions" error code. (3) Theconstants in the
errno
 namespace are all negative. You do not have to explicitly negate them before comparing themwith the Linux system call return result (as you would when using the C constant declarations).
 2Linux System Calls, by Functional Group
 This section will describe the syntax and semantics of some of the more common Linux system calls, organizedby the type of the call.If you read the Linux on-line documentation concerning the system calls, keep on thing in mind. C StandardLibrary semantics require that a system call return "-1" for an error and the actual error value is in the
errno
 globalvariable. Direct Linux system calls don’t work this way. They usually return a negative value to indicate an error anda non-negative return value to indicate success. The error values that Linux functions typically return is the negatedcopy of the value the "C" documentation describes for
errno
 return values.
 2.1File I/O
 This section describes the Linux system calls responsible for file I/O. The principal functions are open, close,creat, read, write, and llseek. Advanced users make want to use some of the other functions as well.

Activity (12)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Yogi54 liked this
eribasajr3398 liked this
michel.urvoy3399 liked this
jwangjw7631 liked this
joao brito liked this
jfscrbd liked this
johnsundarraj liked this

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->