O cliente do sistema de arquivos distribu�dos ter� uma arquitetura mais complicada do que a do servidor. Nossa inten��o nesse projeto � deixar a comunica��o com o servidor CORBA transparente �s aplica��es do sistema. Para atingir essa transpar�ncia, com um desempenho aceit�vel, a maneira mais adequada � inserir um novo sistema de arquivos dentro do sistema operacional utilizado. Dessa forma as aplica��es poder�o continuar usando as chamadas ao sistema sem ter ``ci�ncia'' de que est�o acessando arquivos remotos.
A fim de atingir essa transpar�ncia para as aplica��es, o cliente do sistema de arquivos distribu�dos ser� dividido em duas partes: um m�dulo para o n�cleo do Linux, e um cliente CORBA.
O m�dulo do nosso sistema cliente tem como fun��o disponibilizar um sistema de arquivos para ser montado localmente. Al�m de registrar o sistema de arquivos (utilizando a chamada register_filesystem do VFS), esse m�dulo deve disponibilizar ao n�cleo todas as opera��es que um sistema de arquivos precisa implementar (via a estrutura super_block do VFS). Na realidade, a priori, os membros do super_block deveriam ser ponteiros para fun��es que acessam o servidor CORBA remoto. Essa solu��o n�o foi adotada e explicaremos o porqu� na pr�xima se��o.
A solu��o que achamos mais apropriada � fazer com que o m�dulo do n�cleo converse com um cliente CORBA local, via um dispositivo virtual. As fun��es do super_block na verdade ser�o ent�o env�lucros para escritas ao dispositivo virtual que ser�o lidas pelo cliente. Assim o cliente CORBA local � um processo em espa�o de usu�rio, externo ao n�cleo, que tem a fun��o de se comunicar com o servidor de arquivos CORBA remoto, e servidor de nomes CORBA. Ap�s o recebimento das mensagens do servidor de arquivos, o cliente deve repassar tudo ao m�dulo do n�cleo, que por sua vez disponibiliza � aplica��o que estaria requisitando as informa��es/altera��es sobre os arquivos ou diret�rios em quest�o.
A figura 2 graficamente demonstra a estrutura b�sica que ser� implementada no cliente do sistema.
