ASM51

Chama de sistema no linux:

Chama-se uma rotina adequada.
A rotina dispara uma intrução TRAP (68K na veia).
Em modo supervisor, trata-se a interrupção execulta a requisição.
Retorna ao modo usuario.
Continua execultando a aplicação.

Tão simples, porque não imaginei isso antes?

Será um programa orientado a theats é realmente execultados pelas novas CPUs?

Atomicidade só acontece em sistema uniprocessados, diferente disse, esteja preparado para um overhead terrivel com semaforos.

E mais engraçado é o para que serve a MMU se não é usada? Um ponteiro maluco pode cagar tuda a memoria (a MMU deveria bloquear, mas na pratica tem virus que funcionam apartir disse, se não estou engando), que tudo o que o Linux vai fazer é levantar um Flag, putz...

Atomicidade ocorre no nível de instrução e não de implementação. Por exemplo: as instruções de setar uma interrupção e limpar uma interrupção são atômicas devido ao fato óbvio das mesmas serem necessárias para uso em seções críticas na implementação.

Se semáforo é algo terrível, então o que propõe para solução do problema do jantas dos filósofos (não vale dizer que escreveria o código em uma linguagem funcional, pois as mesmas geralmente fazem uma TRADUÇÃO para C tal qual uma da(s) implementação(ões) de Haskell)?

Oka, sem MMU, então como fica a questão da memória virtual?

Terriveis em termos de consumo de recursos, quase que sem nescessidade em certas situações.

E atomicidade não é garantida em termos de instrução, a não em sistema com apenas uma CPU, que execultam instruções em ordem e não suportem varios Theads.

Mas não se irrite, estou aprendendo e vomitando um pouco aqui, se estiver errado, me corrija, por favor.

Jantar, suruba.

Se a MMU, não proibe o acesso, mas proibir mesmo, perde grande parte da sua função aos meus olhos, e sim, tem a questão da memoria virtual, tambem.

sempre achei que a MMU ajuda a criar um espaço de endereçamento exclusivo para um processo, mas esse espaço de endereçamento é "compartilhado" com o SO e para proteger as páginas, tinha a questão de pemissão de acesso pois cada processo teria um nível de acesso limitado ao SO, a não ser que rode tudo como no Windows, com permissão "liberal", e nesse caso o vírus deita e rola.

não vejo uma forma muito elegante de criar isso em um sistema sem MMU, talvez nem seja tão eficiente, tirando a situação onde o SO tá tomando page fault a doidado por falta de RAM, daí também já é problema do usuário não querer botar memória no sistema.

eh um pouco mais complexo que isso meu amigo!

de uma olhada no manual do 68040 e chore: se vc setar um ponteiro (registro de endereco) e mandar ele acessar em uma pagina marcada como read only, a instrucao vai simplesmente parar no meio antes de gravar qq coisa! se for uma instrucao complexa, como um move16, ele vai fazer um dump dos pipelines do processador na stack e chamar uma trap do sistema operacional. o sistema operacional vai olhar e decidir o que fazer. se for um pagina de codigo ou pagina de outro processo, o trap vai simplesmente abortar a execucao e limpar o lixo. mas se for uma pagina de memoria valida, mas compartilhada entre duas aplicacoes, ele vai duplicar a pagina p/ o processo que quer escrever e entao mapear pela mmu de modo que pareca ser a mesma pagina original. vai retornar da trap e, magicamente o processador vai recuperar aquele dump dos pipelines e continuar exatamente de onde estava, efetivando a escrita em uma pagina agora valida.

entao a coisa nao eh um mero flag, o negocio eh bem mais complexo e, eventualmente, tem que pesar se tanta complexidade vale a pena!

quanto a atomicidade, lembre-se que os semaforos sao usados apenas nos cruzamentos! no resto da quadra vc pode acelerar a vontade. entao, no caso do processador rodando multiplas threads, os cores soh vao se engavetar quando o timer de escalonamento de processo disparar. os semaforos vao evitar q eles escalonem as mesmas threads e daih eles saem andando na boa.

se for pensar q um processador de 1GHz pode escalonar com conforto a 1KHz e, digamos, que vc gaste 1000 clocks p/ escalonar, vc tem um impacto de 1000 em 1 milhao, ou seja, tem 0.1% de impacto na performance.

em termos de impacto SMP ainda eh bem vantajoso!

mastk escreveu:Atomicidade só acontece em sistema uniprocessados, diferente disse, esteja preparado para um overhead terrivel com semaforos.

E mais engraçado é o para que serve a MMU se não é usada? Um ponteiro maluco pode cagar tuda a memoria (a MMU deveria bloquear, mas na pratica tem virus que funcionam apartir disse, se não estou engando), que tudo o que o Linux vai fazer é levantar um Flag, putz...

Marcelo Sam* aproveitando a tua aula, quando AMP é vantajoso sobre SMP e vice e versa?

acho que a propria aplicacao molda isso. se vc tem muito software de uso geral e esse software pode ser quebrado em varias threads concorrentes, quanto mais cores simetricos vc adicionar, melhor vai ser a performance. por outro lado, existem situacoes em que vc nao consegue quebrar a aplicacao em threads concorrentes, possivelmente pq a aplicacao eh muito especifica. entao, normalmente, vc acaba colocando um core dedicado por aplicacao, eventualmente com um core de capacidade e funcionalidade diferente, deixando o sistema bem assimetrico. um exemplo classico eh o MPC860: consiste em um core powerpc p/ aplicacoes de uso geral e um co-processador RISC dedicado para comunicacao. uma variacao do MPC860 eh um MC68360, e ele eh interessante pq permite SMP! quando usado apenas por si, o MC68360 consiste em um mero core 68030 para as aplicacoes de uso geral e um co-processador RISC dedicado para comunicacao. o truque dele eh que vc pode desligar o core, usar apenas o co-processador RISC como periferico inteligente e conectar um ou mais processadores 68040 ou 68060 em configuracao SMP. o layout de memoria em uma situacao destas fica da seguinte forma: memoria DRAM (barata e grande) unificada para os processadores em configuracao SMP e memoria dual-port (cara e pequena) para comunicacao com o co-processador RISC. pelo tamanho e custo vc jah percebe o que vale ou nao a pena rodar em cada sub-sistema. outro exemplo um pouco maior sao sistemas VME, onde vc tem varias placas completas que se comunicam normalmente por memoria de porta dupla. vc pode ter placas contendo sistemas SMP, mas, no geral, o sistema como um todo pode ser composto de placas de processamento geral em SMP e placas de IO em AMP.

bom, se for observar bem, eu soh consegui encontrar exemplos onde AMP eh usado para coprocessamento de IO. para o processamento bruto, no entanto, soh lembro de casos SMP.

chrdcv escreveu:Marcelo Sam* aproveitando a tua aula, quando AMP é vantajoso sobre SMP e vice e versa?

Agora minha vez de perguntar

Marcelo você conhesse o processo em que é executado a Criptografia

no PC ?

Me refiro ao processo em si, e não a Criptografia propriamente,

como nesses Sites Seguros de Cartão de Crédito, etc..

DJ

nao entendi muito bem o que vc perguntou... mas o mecanismo em si eh totalmente baseado em criptografia assimetrica, onde vc tem uma chave publica e uma chave privada, sendo estas chaves matematicamente conectadas. as chaves tambem podem ser usadas como certificados, onde organizacoes externas fornecem as chaves publicas.

o truque funciona da seguinte forma: vc monta um site e cria o par de chaves matematicamente conectadas. vc vai manter a chave privada no servidor, fora do alcance de todos, enquanto a chave publica sera fornecida para qq um que quiser. em especial, vc pode divulgar sua chave publica atraves de uma organizacao externa, que certifica que a chave publica eh realmente sua.

essa criptografia assimetrica eh usada apenas para estabelecer a conexao. uma vez certificado que vc eh vc, a criptografia assimetrica troca uma chave simetrica, que sera utilizada para a transferencia em si.

a melhor explicacao que eu achei eh essa aqui:

http://pajhome.org.uk/crypt/rsa/intro.html

o processo, no mundo real, eh assim:



normalmente a criptografia simetrica eh algo entre 40 e 128 bits, enquanto que a criptografia assimetrica eh entre 512 e 8192 bits. a diferenca eh justamente pq a chave publica eh visivel para todos! em teoria, vc pode determinar a privada atraves de tentativa e erro ateh casar as chaves, mas como sao muitos bits, vc acaba nao conseguindo quebrar.

na pratica mesmo eh simples: criar as chaves e certificados e entao configurar um apache no linux. o apache usa a biblioteca SSL para suprir a criptografia e vai trabalhar na porta 443, q eh a porta q o browser usa quando vc usa o prefixo https://...bom, eh assim.

Djalma Toledo Rodrigues escreveu:Agora minha vez de perguntar

Marcelo você conhesse o processo em que é executado a Criptografia

no PC ?

Me refiro ao processo em si, e não a Criptografia propriamente,

como nesses Sites Seguros de Cartão de Crédito, etc..

DJ

Bem interessante

Obrigado Marcelo

DJ

caramba, estou rodando o Mint12, em um maquina virtual e esta melhor que o windows nativo!!!

Para quem quer comecar, basta ir aplicativos, outros, genrenciador de programas e pegar tudo o que vc precisa, no estilo AppStore, soh que tudo na faixa, nessas poucos horas o linux esta sendo uma experiencia BEM agradavel.

mastk
Enviada: Seg Abr 30, 2012 2:06 am Assunto:
caramba, estou rodando o Mint12, em um maquina virtual e esta melhor que o windows nativo!!!

Para quem quer comecar, basta ir aplicativos, outros, genrenciador de programas e pegar tudo o que vc precisa, no estilo AppStore, soh que tudo na faixa, nessas poucos horas o linux esta sendo uma experiencia BEM agradavel.

Tem bastante programas pra baixar porque o Mint12 é baseado no Debian, onde o repositorio é enorme.

Se também tu baixar todos os DVDs do Debian, teras todos os programas a mão.