Dificuldades no Cliente

Ao projetar o cliente do sistema encontrou-se uma dificuldade, cuja solução resultou na arquitetura adotada. O principal problema encontrado foi descobrir como realizar a comunicação entre o módulo (ou núcleo em si) e o servidor CORBA externo. Duas opções foram cogitadas para solucionar o problema:

1. Inclusão de um ORB dentro do núcleo do Linux. Essa solução, de fato, resolveria o nosso problema já que o módulo teria um stub e ORB próprio e a comunicação entre o cliente e servidor CORBA seria bastante eficiente.

2. ORB cliente como processo ``externo'', em espaço de usuário. Essa solução é um pouco mais complexa, pois exige mais uma camada separando o módulo/núcleo e o servidor de arquivos. Além do mais, pode acarretar em alguma degradação de desempenho.

Apesar da opção (1) parecer ser mais simples e mais eficiente infelizmente a solução adotada foi a da opção (2). As razões para não adotar a solução (1) são basicamente três. Primeiramente haveria a necessidade de integração de um ORB no núcleo do Linux. Procurou-se um ORB estável e pequeno para o núcleo do Linux e o único encontrado foi kORBit³ que aparentemente não está estável e cujo desenvolvimento está atualmente parado. Além disso o módulo a ser desenvolvido não funcionaria em qualquer núcleo do Linux, apenas naqueles com o patch incluindo esse ORB. Em segundo lugar os ORBs vistos consomem muita memória, o que é extremamente indesejável para inserção dentro do núcleo de um sistema operacional. Por fim o tempo hábil e energia necessária para viabilizar a integração de algum ORB existente (ou criação de novo) no núcleo do Linux, seria demais para esse projeto.

Com isso, foi decidido utilizar a alternativa (2). Essa alternativa também trouxe outro problema que é o de se fazer um upcall, isto é, o núcleo fazer uma chamada a uma função de um processo em espaço de usuário. O upcall é uma operação atualmente não permitida pelos núcleos padrões do Linux. Existe um patch que fornece essa funcionalidade, desenvolvida por Alessandro Rubini⁴, que pode ser vista em: http://www.linux-mag.com/2000-11/gear_01.html. Entretanto essa nova funcionalidade exigiria, novamente, muitas mudanças ao núcleo padrão do Linux, e tomaria muito tempo e energia.

Uma maneira que se pensou para ``simular'' os upcalls seria o uso de chamadas RPCs locais para o processo cliente. Para esse projeto, quase decidiu-se implementar uma solução usando chamadas RPCs. Era de se esperar que essas chamadas não ocasionam muito custo adicional, já que todas as chamadas deveriam ser chamadas locais (na mesma máquina), entretanto não se tem como comprovar essas suposições até experimentar-se uma implementação. Outro problema é que a complexidade do código deve aumentar, pois seria necessário criar mais uma interface e utilizar mais outro protocolo de comunicação.

Outra solução para a falta de upcalls no núcleo do Linux, é a solução adotada pelo projeto Coda FS⁵, sistema de arquivos distribuídos desenvolvido pelo universidade CMU. No Coda FS o processo cliente rodando comunica-se com o módulo do núcleo através de uma entrada no /dev/. O processo cliente é um gerenciador de cache (Venus) que se comunica com o servidor (Vice) utilizando RPC. O gerenciador escreve o arquivo em um sistema de arquivos local e notifica o módulo novamente via o dispositivo virtual. Assim o núcleo pode manipular o arquivo com operações em um sistema de arquivos local (como o ext2).

Apesar da arquitetura do Coda FS ser extremamente avançada, permitindo tolerância a falhas e realização de operações desconectadas, ela não será usada. A desvantagem nesse caso é a dificuldade de implementação de um gerenciador de cache utilizando o disco como meio de troca de informações com o núcleo. Outro grande empecilho é a dificuldade em manter os arquivos consistentes no servidor e entre os cliente; essa operação torna-se mais complicada com o uso de caches locais.

Por fim, ao pesquisar o Parallel Virtual File System⁶ (PVFS), cuja arquitetura foi fortemente baseada na do Coda FS, achou-se que essa seria a arquitetura ideal de comunicação entre o módulo do núcleo e o cliente local. A comunicação usada no PVFS entre o módulo e o cliente local (no caso do PVFS é um daemon ao invés de um gerenciador de cache como é o do Coda FS) é bem parecida com a do Coda FS, só que não é feito o uso de algum sistema de arquivos local.

Basicamente, os upcalls são implementados utilizando o dispositivo virtual /dev/pvfsd. O daemon, chamado pvfsd, lê as requisições desse dispositivo, e quando elas são satisfeitas, escreve uma resposta no mesmo dispositivo. O módulo do kernel então, utiliza funções do núcleo como copy_from_user e copy_to_user para transferir os dados dos arquivos sendo manipulados entre o núcleo e o cliente local.