johnl@n3dmc.UU.NET (John Limpert) (03/22/90)
Are the 80386 UNIX systems from AT&T, ESIX, Intel, ISC and SCO compatible at the device driver level? I am interested in upgrading from Microport System V/AT to an 80386 UNIX. ESIX looks like the best deal but the question of vendor support bothers me. Is it possible to link a vendor supplied device driver into the ESIX kernel even though the device driver was written for ISC UNIX? Can I still run programs that were compiled and linked under Microport System V/AT? -- John A. Limpert I'm the NRA! Internet: johnl@n3dmc.UU.NET UUCP: uunet!n3dmc!johnl
cpcahil@virtech.uucp (Conor P. Cahill) (03/23/90)
In article <912@n3dmc.UU.NET> johnl@n3dmc.UU.NET (John Limpert) writes: >Are the 80386 UNIX systems from AT&T, ESIX, Intel, ISC and SCO >compatible at the device driver level? They can be. However, it depends upon the writer of the code. If they don't use any special kernel functions the drivers will probably work. > I am interested in >upgrading from Microport System V/AT to an 80386 UNIX. ESIX looks >like the best deal but the question of vendor support bothers me. >Is it possible to link a vendor supplied device driver into the >ESIX kernel even though the device driver was written for ISC UNIX? Usually you can do this. However, the problem is that each of the vendors have a slightly different driver installation that doesn't work on the others. I have taken a Maxspeed serial i/o card driver which was made for interactive and manually installed it on a Bell Technologies System V/386 system without any problems (other than having to manually do the installation). >Can I still run programs that were compiled and linked under >Microport System V/AT? Yup. Again, with the limitation that they are not doing anything special with microport drivers, etc. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
peter@ficc.uu.net (Peter da Silva) (03/23/90)
In article <912@n3dmc.UU.NET> johnl@n3dmc.UU.NET (John Limpert) writes: > Are the 80386 UNIX systems from AT&T, ESIX, Intel, ISC and SCO > compatible at the device driver level? Some are, some aren't. For some reason ISC (and I think ESIX) uses a slightly different structure in /etc/conf, and a slightly different set of predefined system calls, than the Intel/AT&T baseline. You have to jam drivers in, and if they just communicate through the standard system calls they might work. The same products are available for both branches (eg., VPIX), but unless you have the source they won't work. > Is it possible to link a vendor supplied device driver into the > ESIX kernel even though the device driver was written for ISC UNIX? Probably. I have read on the net that ESIX is an ISC derivitive. > Can I still run programs that were compiled and linked under > Microport System V/AT? Probably. But it's in an emulation mode so you won't get the performance of the 386... they may even run slightly slower due to differences in memory allocation (at least that's our experience). I'd really recommend recompiling. -- _--_|\ `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ 'U` \_.--._/ v
rick@pcrat.uucp (Rick Richardson) (03/28/90)
In article <GKF29:xds13@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >Some are, some aren't. For some reason ISC (and I think ESIX) uses a >slightly different structure in /etc/conf, and a slightly different >set of predefined system calls, than the Intel/AT&T baseline. There doesn't appear to me to be any difference in the structure of /etc/conf in ISC from the stock AT&T structure except for the presence of the kconfig.d directory. Our software, which includes a couple of device drivers, comes in standard AT&T ID format and installs and builds under ISC, AT&T, and SCO. Note that you and any device driver packages that you install can ignore what is in the kconfig.d directory under ISC UNIX if you always use the AT&T idbuild (rather than ISC's kconfig) to build new kernels. A device driver that wants to be fully compatible with either method of kernel build under ISC needs to add a single line to the end of kconfig.d/description. In fact, in my opinion, a 3.2 variant that is not downwards compatible with the AT&T ID format isn't worth a dime. I only know of one system like this, which is 3.2 stuff Unisys is selling. To be fair, they have run time loadable drivers; (something I was disappointed didn't make it into everybodies 3.2) but they started and didn't finish the job of making them coexist within the ID format. The grey areas with drivers are with the internal driver support functions. You can depend on the standard ones that have been around since V7. But when you get into less well known areas, each vendor diverges with their own 'invented here' method. To have any chance of portability, a driver writer needing these functions must use the ones that AT&T provides in their 3.2 and hope that the variant UNIX vendor hasn't deleted support for that call. We've been burned by this approach only recently, again with Unisys (they apparently aren't found of 3rd party SW). -Rick -- Rick Richardson | Looking for FAX software for UNIX/386 ??? Ask About: |Mention PC Research,Inc.| FaxiX - UNIX Facsimile System (tm) |FAX# for uunet!pcrat!rick| FaxJet - HP LJ PCL to FAX (Send WP,Word,Pagemaker...)|Sample (201) 389-8963 | JetRoff - troff postprocessor for HP LaserJet and FAX|Output