Cara, system calls…
o conceito vem do assembly. No Linux, as chamadas diretas ao SO são feitas pela INT 80:
MOV EAX, 10h;
MOV EBX, 0;
PUSH EBP;
MOV EBP, ESP;
ADD ESP, 4;
INT 80h;
Não faço idéia do que acontece ao rodar o código acima. Mas vc tem razão quanto a alguns pontos:
- numa system call, pode haver troca de contexto. Digo pode porque as otimizações fazem com que um SO decente faça a maioria das coisas em “modo usuário”. Normalmente, alocação de memória, acesso ao hardware (nem todo hardware) e gerenciamento de processos são feitos em “modo kernel”. Hoje em dia, muitos hardwares utilizam DMA, que nada mais é que um buffer em que apenas a exclusão mútua é feita pelo processador, a leitura e escrita são feitas diretamente.
1b) Mas não tem TRAP nenhuma. TRAP, se eu entendi o que vc disse, envolve sinais de processo (SIGNALs), que não têm nada a ver com a hstória.
-
Isso mesmo, o código está implementado pelo kernel. Por exemplo, ao abrir um arquivo, vc precisa de um File Descriptor. O Kernel é quem gerencia o mapa de FDs (aliás, é ele que garante que o stdin e o stdout vão pro lugar certo), e o código desse gerenciamento está no kernel.
-
A libc implementa coisas em cima do kernel. Em cima do open, que pode abrir qq coisa que tenha um File Descriptor (por exemplo, um socket INET), a libc implementa o fopen, que já faz buffering pra você, e é especializada em arquivos no disco.
Como funciona a libc depende muito do SO e de como vc compila o seu programa. No final das contas, vai virar tudo MOV EAX… no linux, por exemplo, existem duas implementações da libc que ficam brigando. uma é a Gnu Libc, ou a GLIBC, e quem usa algo feito com GTK já sabe a dor de cabeça que é atualizar sua versão dessa lib. Tem uma tal de stdc++, que implementa a libc também, mas (agora chutando forte) provavelmente é otimizada para uso em C++.
Vc pode compilar estaticamente a lib (o que eu não recomendo) ou deixar a lib para ser linkada dinamicamente (alguém falou em DLLs? Alguém disse que o Linux não tem DLLs??).
A diferença é a mesma de vc pegar as classes do pacote java.* e colocar dentro do seu JAR e ainda forçar que essas classes sejam as carregadas. Ou seja, em vez de vc usar o jre do cliente, vc deu suas próprias classes. Se a Sun lançar uma correção de BUGs, vc ainda vai usar as classes velhas. Se vc deixa a linkagem dinâmica, pode se beneficiar de código escrito depois de você ter finalizado e distribuído seu programa.
Por outro lado, isso pode ser ruim com coisas “deprecated”. Um dia, espero, elas vão sumir, e ninguém mais vai poder usar aqueles códigos horríveis. Mas se vc precisa de uma API deprecated… entendeu?
Se vc encontrar incompatibilidades entre o que eu disse e o que o seu livro disse, confie no seu livro… 8)
[]s
