🚀 go-pugleaf

> > encargan de llamar a las respectivas "llamadas al sistema", que
necesiten,
> > que son menos; en ensamblador he leido que es la int 80h (no estoy
seguro),
> > pero los parametros se pasan por pila y no por registros.
> Te equivocas... Los par�metros en linux se pasan por registros, aunque en
> llamadas complejas normalmente uno o dos de los registros es un puntero
> a una zona de memoria del proceso que contiene una estructura con un
> buen n�mero de par�metros.

Se pasan dos parametros por registro, el primero indica el servicio que se
quieres llamar, es sys_call_num, que se encuentra en la tabla
sys_call_table[], y el segundo sys_call_args son el n�mero de argumentos en
pila. Y ahora afirmo que es con int 0x80. Si realmente se pasan m�s de estos
dos, dime donde lo ves, porque yo no lo encuentro, pero puede que tengas
raz�n.

> > Si lo que quieres es llamarlas directamente, no te lo aconsejo, entre
otras
> > cosas por que pueden cambian con cada n�cleo, pero no tienes problema
porque
> > se enlanzan en memoria din�micamente, y si miras include/linux/sys.h
ver�s
> No te confundas. Si llamas con INT est�s no se enlazan ni nada. Si haces
> un ejecutable normal entonces no haces las llamadas directamente sino a
> trav�s de la libc. En este caso SI se enlazan y los par�metros se pasan
por
> la pila.
> Pero la libc trabaja al mismo nivel tu aplicaci�n. Solo facilita las
tareas
> y aumenta la compatibilidad.

A lo mejor es que no me he explicado bien. Cuando digo "se enlazan en
memoria din�micamente", quiere decir "en tiempo de ejecuci�n". JAM�S una
llamada al sistema es enlazada junto con el ejecutable, ya que eso ser�a
romper toda la protecci�n de los Sistemas Operativos, y el Hardware
existente, otra cosa es la llamada a esa "puerta de llamada", la cual va
un�da al ejecutable irremediablemente (que es la instrucci�n int de la que
hablas).

> > ten�an. Por eso cuando sale un fallo de seguridad, no tienes que
recompilar
> > todos los programas, s�lo el n�cleo que es el que corrige el fallo, por
que
> > enlaza din�micamente en tiempo de ejecuci�n.
> Esto... Depende de donde sea el error. Lo normal es que el error sea de
una
> aplicaci�n determinada (un buffer overflow o algo similar) y sea lo que
haya
> que cambiar.
> Tambi�n puede ser que sea del kernel (como lo que paso con los inferiores
> a la 2.2.16) y sea lo que haya que upgradear.

Una aplicaci�n puede tener fallos, y se corrigen cuando se encuentran. Pero
si tu haces un fork() (que es una "llamada al sistema") esperas que se cree
un proceso hijo, con los mismos datos que tiene el padre; supongamos que uno
de ellos intenta modificar una variable, y en este punto el programa falla,
por que se han modificado los datos del padre y del hijo a la vez; de quien
es la culpa del programa o de SO. Del SO, por qu�, porque como en el fork()
el segmento de datos no se copia hasta que alguno de los dos, intenta
modificarlo no ha cumplido su misi�n, esa aplicaci�n no hay que
recompilarla, ya que como las llamadas al sistema se producen en tiempo de
ejecuci�n, lo �nico que hay que hacer es corregir esa llamada al n�cleo del
SO, y todo solucionado.

No se pueden confundir los errores de un programa, con los del SO, es m�s si
programas te aconsejo mirar /usr/src/linux/include/asm-386/unistd.h y
/usr/src/linux/arch/i386/kernel/entry.S, aparte de un libro que es muy bueno
Linux kernel internals de M. Beck, H. B�hme, M. Dziadzka, U. Kunitz, R.
Magnux y D. Verworner. Aqu� encontrar�s todo sobre el n�cleo de Linux y sus
interioridades. Espero se te de mejor que a m� el ingl�s.

---------------------------------
jespejoYASABES@QUEHACERarrakis.es
�Sistemas Operativos? �Vis�tala!
http://www.arrakis.es/~jespejo
---------------------------------