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:
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 kORBit3 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 Rubini4, 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 FS5, 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 System6 (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.