Xref: utzoo comp.unix.xenix:3289 comp.unix.questions:9166
Path: utzoo!attcan!uunet!husc6!spdcc!dyer
From: dyer@spdcc.COM (Steve Dyer)
Newsgroups: comp.unix.xenix,comp.unix.questions
Subject: Re: SCO Xenix 286 TCP/IP?
Keywords: New Ethernet
Message-ID: <1834@spdcc.COM>
Date: 11 Sep 88 12:16:10 GMT
References: <3606@charon.unm.edu> <176@ispi.UUCP> <1860@turnkey.TCC.COM>
Reply-To: dyer@spdcc.COM (Steve Dyer)
Organization: S.P. Dyer Computer Consulting, Cambridge MA
Lines: 25

In article <1860@turnkey.TCC.COM> sandy@turnkey.TCC.COM (Sanford 'Sandy' Zelkovitz) writes:
>I truely agree with you about The Excelan Hardware and software; however,
>you would think that after MANY requests from customers about supporting
>"compatible" NFS, they would. Like many other companies, we have Sun
>workstations and VAXs running under NFS; however, our 286 and 386 systems
>cannot share that luxury.

If you understood what it meant to provide a "compatible" NFS client,
you would understand that Excelan, which provides only a TCP/IP card with
a set of private utilities, has no access to the higher NFS/RPC layer which
must necessarily be integrated tightly into the kernel.  A device driver
is too low an interface, and without UNIX sources, that's all they have to
work with.  It would be much less work to provide an NFS server so that
your XENIX disks could be made accessible to your Suns and VAXes; however,
that's probably not what you're looking for.

I know that SCO is working on a port of NFS to their version of XENIX/UNIX
(probably the Lachman Sys V stuff, although I could be wrong), and at that
point you could start asking the question you ask here, since Excelan's
job would be to splice their IP processing beneath the kernel's RPC layer.

-- 
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {harvard,husc6,linus,ima,bbn,m2c,mipseast}!spdcc!dyer