Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site topaz.RUTGERS.EDU Path: utzoo!watmath!clyde!burl!ulysses!unc!mcnc!philabs!cmcl2!harvard!seismo!caip!topaz!root From: root@topaz.RUTGERS.EDU (Charles Root) Newsgroups: net.unix-wizards,net.lang.lisp,net.ai Subject: Re: using Vax as fileserver for Xerox Lisp machine Message-ID: <4221@topaz.RUTGERS.EDU> Date: Tue, 19-Nov-85 05:34:39 EST Article-I.D.: topaz.4221 Posted: Tue Nov 19 05:34:39 1985 Date-Received: Thu, 21-Nov-85 03:56:44 EST References: <169@ecrcvax.UUCP> <354@tove.UUCP> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 41 Xref: watmath net.unix-wizards:15790 net.lang.lisp:643 net.ai:3109 We think Xerox is still not very close to being able to remove PUP support. From the user's point of view, PUP is much more useful than you suggest. First, I don't know what you mean when you say it is vanishing from 4.3. It wasn't in 4.2 to begin with. PUP is distributed separately from 4.2, as a set of modifications that have to be added. It consists of a set of user-level code, a device driver, and a couple of very small hooks in the Ethernet device driver. It was carefully designed to be as separate as possible from the rest of the kernel. I find it hard to believe that 4.3 is doing anything that would make it impossible to install the modifications. I realize that 4.2 has some modules that seems to be related to PUP. These modules are not used by the actual PUP implementation, so their removal would not cause any problem. The PUP implementation uses /dev/enet, which is a general-purpose Ethernet packet filter. It allows the user to specify tests that define what packets he is interested in seeing. Thus it can be used to implement any protocol. In fact, we use it here to implement PUP, PUP Arp, Internet Reverse ARP, and a small subset of XNS (nothing exciting, just time of day and telling Interlisp workstations what their PUP host number is). The hook into the kernel effectively reorganizes the switch statement in the packet-input routine so that any packet not otherwise recognized is sent to the /dev/enet driver for processing. Second, as far as I know, PUP is the only protocol currently used by Interlisp that supports random access. This means that TCP/IP is not a replacement for it. Unless something has changed recently, XNS isn't either. Third, even if XNS were a replacement, sites such as ours would need a portable implementation of an XNS file server on Unix. I note that this is still absent from the list of XNS support you gave. In order for us to use it, we would have to be able to port it to the Pyramid 90x. The XNS situation is certainly getting better as time goes on, but at the moment Xerox has not done what is necessary to replace PUP with XNS. We know that this is a goal, but we trust that they will not be sufficiently suicidal to remove PUP from Interlisp before all of their customers are able to replace its functionality with something else. What I am hoping for is a file server protocol that supports random access and runs on top of TCP/IP. The PUP file server protocol (LEAF) runs on top of PUP's equivalent of UDP. It could probably be moved to work on top of UDP without too much trouble.