Vendors cannot provide all the operating system services that users demand. As a result, there has been a persistent desire to make operating systems more flexible and customizable. It is natural that object-oriented technology would come to bear on this area. However, many solutions have been disappointing when it comes to ease of use. This paper describes the design and implementation of Frigate, an object-oriented file system. The goal of Frigate is to provide a modular, extensible framework. The framework allows new extensions to be "plugged-in" on the fly. Frigate's focus differs from most other file system designs in that it is targeted for use by ordinary users rather than by sophisticated operating system gurus. Thus, ease of use is a very important concern in the design. Frigate is fully implemented and supports a set of example file system extensions.

There exist a wide-variety of communication-intensive applications which run in networks and platforms of greatly varying characteristics. This implies the need for application level communication optimization, which is the optimization of network communication by exploiting application semantics as well as network and compute node characteristics. In this paper, we propose a flexible object-oriented framework called FALCON for application level communication optimization by allowing complementary network communication optimization techniques to be combined in the form of matching stack layers at the endpoints of a communication channel. Each stack layer is composed of a pair of matching modules, executed in the sender and receiver endpoints respectively. To exploit application knowledge that is only available to one of the communicating peers, the framework allows an executable stack layer module to be supplied by either of the communication peers and provides for safe transport to an...

This memory reallocation is done to 70 allow the library to allocate the exact memory required dynamically. When an asymmetric-key size of over 1024-bits is used the kernel tries to allocate more than the kernel limit of 128k of memory. Fixing this problem requires modification of the memory allocation routines of the GNU MP library to use virtual memory when the kernel memory limit is reached. 3. Currently the keys generated in CryptosFS are stored in a link-list in the memory of the kernel and are transferred into and out of a file from memory when the CryptosFS module is inserted and removed from the kernel. This method performs adequately for small numbers of files but it is not scaleable. A more efficient mechanism would require the modification of the ext2 file system to store the keys directly. 4. The current prototype of CryptosFS stores the keys generated for each vnode in clear text format. Applying encryption to the key files provides security of this information. A password program could be developed to allow decryption of these keys. This is a simple solution although it is not the preferred solution as the difficulty of compromising the system is reduced to the difficulty of breaking the password. A more secure solution would be to investigate the use of a magnetic card to store the access key on. 6.4 Conclusion

The papers at this Convention have been selected on the basis of a submitted abstract and extended precis that have been peer reviewed by at least two qualified anonymous reviewers. This convention paper has been reproduced from the author’s advance manuscript, without editing, corrections, or consideration by the Review Board. The AES takes no responsibility for the contents. Additional papers may be obtained by sending request and remittance to Audio