Bristot’s Blog

A culpa para eu não ter postado mais é uma só: é muita tecnologia para uma pessoa só!
Nessa vida de acadêmico, profissional e hobbista estou tendo que lidar com coisas tanto em baixíssimo quanto altíssimo nível;
A começar pela vida acadêmica, este trimestre a cadeira é de sistemas distribuídos, o contexto é:

• comunicação com utilização de mensagens;
• protocolos e semânticas;
• tratamentos de erros, correções, tolerância a falhas;
• tempo distribuído, ordens causais, exclusão mútua distribuída;

A linguagem de programação definida pelo professor (define:professor – Alguém que não é legal você contrariar) é JAVA. Sabe já fui xiita quanto a isto, mas para algumas coisas o Java realmente é uma mão na roda, por exemplo, faziam 4 anos desde a última vez que eu fiz um programa com janelinhas, e com Java consegui fazer um programa demo em menos de meia hora.

Outro ponto é: Objetos remotos. O Trabalho deste trimestre é fazer uma implementação utilizando Corba, e com Java isto é legal é muito simples compartilhar um objeto remoto utilizando Java, e eu sinceramente não sei porque este protocolo junto com o RMI (que é mais fácil ainda) não são utilizados em larga escala.

Saindo um pouco da vida acadêmica, caio na minha vida profissional, ai entramos em um outro extremo. Ai o contexto é outro:

• kernel Linux, uCLibc, arm-linux-*
• ARM, Atmel, TI
• C e asm
• NandFlash, Dataflash, EEPROM
• 32MB, 4KB, 99Mhz…

E esta é a minha praia, eu sinceramente, sem brincadeira, fico feliz com os problemas que me aparecem lá, os últimos que me vem a cabeça…

• fazer o suporte da INFERNO PACK para o u-boot mainline;
• um patch com os drivers do INFERNO PACK para o kernel mainline e resolver os pepinos da integração deste com o PREMPT_RT;
• resolver um problema da implementação de mutex na linuxthreads da uCLibc;
• por o 2.6.33.5-rt + buildroot-2010.05 + um monte de aplicação em 3.5MB de dataflash;
• provar para o pessoal do outro lado do barramento que a latência não é no Linux (eu adoro este);

Mas ultimamente um problema legal que tenho trabalhado é o fato do processador Atmel at91sam9g20 não conseguir ler a uma NAND Samsung de 512 mbit, faz mais de um mês que estou discutindo com a Atmel que o problema é a ROMBOOT do processador. O legal disto é que estou tendo bastante contato com o drivers/mtd/ e o código do bootstrap do processador.

Por fim, o lado hobbista… aaa, este é uma coisa só: kernel Linux/Tempo real. Pra quem não sabe, minha proposta de palestra para a LinuxCon foi aceita, em breve publicarei aqui o resumo dela e os slides. Mas bom, voltando ao assunto, ultimamente tenho lido bastante sobre tempo real, tanto teoricamente com o livro Real Time Systems quanto implementações no kernel Linux, como a implementação do HRT, DynTick, a proposta do escalonador EDF, alguns artigos sobre controle de admissão de processos de tempo real.

Enfim, como pode-se ver, meu tempo ultimamente tem passado desde registradores à objetos distribuídos… porém, pelo meu lado hobbista… tudo se resume na frase do Linus…

And yeah, I still think the hard-RT people are mostly crazy. — Linus;

#include 
#include 
#include 

/* based on code lighttpd:server.c source file */

void daemonize(void) {
        signal(SIGTTOU, SIG_IGN);
        signal(SIGTTIN, SIG_IGN);
        signal(SIGTSTP, SIG_IGN);
        if (0 != fork()) exit(0);

        if (-1 == setsid()) exit(0);

        signal(SIGHUP, SIG_IGN);

        if (0 != fork()) exit(0);

        if (0 != chdir("/")) exit(0);
}

int main(){

	int i;
        printf("Perhaps you want do something before go to background\n");
	scanf("%d", &i);

	daemonize();

	for (;;){
		sleep(10);
	}

}

A tempos que venho me interessando pelo desenvolvimento de sistemas, principalmente embarcados, e isto me fez, no final do ano passado buscar um tema de TCC que pudesse ser um DEMO de como é esta área… dei sorte; consegui junto a equipe de pesquisa e desenvolvimento de software da empresa qual trabalho o tema: QoS em rede para central VoIP em Linux embarcado, pronto, era o que eu queria, Linux embarcado, C e redes, estou em casa.

No decorrer do primeiro semestre deste ano, grande parte do meu tempo livre, incluso finais de semana, foram dedicados a isto, e não é que peguei gosto pela coisa?

Ao mesmo tempo, via os grandes desafios da administração de sistemas ficarem cada vez menores… Com o tempo, tudo aquilo que era complexo e novo, tornou-se rotina… e o brilho foi diminuindo…

Certo dia, vi um discurso do Steve Jobs, onde ele falou algo como, “se hoje fosse seu ultimo dia, você gostaria de fazer o que está prestes a fazer hoje?”, e então, a cada manhã ao me perguntar, repetidamente, a resposta era: isto não me faz mais feliz… Queria algo novo. queria algo com desenvolvimento de Linux embarcado, C e redes…

Então decidi correr atrás, e felizmente, consegui uma transferência, após alguns namoros, na mesma empresa que trabalhava, para o desenvolvimento de centrais telefónicas, trabalhando com Linux embarcado, redes e C…

Esta foi a primeira semana na nova profissão, e todos os dias dessa semana, ao acordar, a resposta foi, sim, é aqui onde estavam meus ídolos, (Ken Thompson, Denis Ritchie), é aqui que quero estar… Linux embarcado, C e redes…

Os sockets possuem algumas opções e ajustes que podem ser feitos, como por exemplo, o tamanho do buffer de envio e recebimento de pacotes, se o pacote pode ser enviado para broadcast (este somente para sockets de datagrama (ex: UDP)), o TTL do pacote, etc.

Um dos meios de ajustar estes valores é utilizando as chamadas do sistema getsockopt(2) e setsockopt(2)

Os argumentos, são:

int s: Descritor do soquete aberto
int level: Nivel do protocolo que deseja alterar a opção (ip, tcp, udp…)
int optname: Opção que deseja alterar
void *optval: Um ponteiro para a variável ao qual o valor deve ser gravado em getsockopt() ou lido em setsockopt().
socklen_t optlen: Tamanho da variável optval

Os valores para level, optname e optval estão descritos nas sessões “Socket Options” de ip(7),tcp(7),udp(7),socket(7) e unix(7).

O código abaixo, trás dois exemplos de opções:

• Aumentar o tamanho do buffer de recebimento
• Liberar o envio de pacotes UDP para o endereço de broadcast da rede:

sockopt.c Continue reading ‘(get|set)sockopt’ »