Messages in this thread |  | | Date | Fri, 26 Jul 1996 13:03:36 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: Alternate solutions (Was: Re: NFS still has caching problem) |
| |
Date: Fri, 26 Jul 1996 00:03:25 -0400 (EDT) From: G Sumner Hayes <sumner+@cmu.edu>
Not AFS, DFS. Even CMU is planning on shifting to DFS in the near future as it addresses some of the problems in AFS.
Err... funny, I just came back from the Cartel meeting (a meeting of CMU, Stanford, U Mich, MIT, and other schools to compare notes and with our counterparts about providing good central I/S to our schools), where people like John Leong and Walter Wong (the Andrew System Manager) were there, and they didn't mention anything about a move to DFS anytime soon.
A Linux DFS implementation would be a Very Good Thing, IMO.
Certainly, it wouldn't be a bad thing. However, DCE and DFS are *very* complicated. The place to start is the freeware OSF/1 release of the DCE RPC, which requires among other things DCE threads (which wasn't released). So you'd have to take the DCE RPC, and port it to use a modern POSIX threads interface.
Next, you'd have to write the client-side interfaces of the DCE directory server (if not a server-side interface to actually test the client-side code, if you don't have a DCE environment).
Next, you'd have to rewrite the DCE Security Service (client and server), which is based on Kerberos V5, but has a lot of extra hair added, and which has been changed to be based on DCE RPC. Just about the only part of DCE which you wouldn't have to reverse engineer and reimplement is the DCE Time Service --- we could use NTP instead.
Finally, after all of this infrastructure is recreated, you could think about trying to cram all of the client side stuff of all of the above into the kernel, and then try to implement the DCE DFS.
Good luck. It's doable, but it's a very, very, very big project.
- Ted
|  |