NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/unix/sysv386/16674

Text File | 1992-11-21 | 3.6 KB | 75 lines

Newsgroups: comp.unix.sysv386
Path: sparky!uunet!europa.asd.contel.com!emory!sol.ctr.columbia.edu!ira.uka.de!math.fu-berlin.de!fub!geminix.in-berlin.de!gemini
From: [e-mail] (Uwe Doering)
Subject: Re: Using 16550AFN with SCO 3.2.4
References: <[e-mail]>     <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Private UNIX Site
Date: Sat, 21 Nov 1992 13:06:42 GMT
Message-ID: <[e-mail]>
Lines: 64

[e-mail] (william E Davidsen) writes:

>The one thing about the SCO driver is that
>it seems to support more types of serial device than FAS, although you
>have source with FAS.

I can't really believe that SCO's driver supports more serial device
types. While it is true that FAS comes with config files for only
a few serial cards, FAS' support is in no way limited to these cards.
The config files included in the FAS distribution are _sample_ files.
The config mechanism in the `space.c' file is powerful enough to
support almost every serial card design one could think of, as long
as it uses 16450, NS16550A or i82510 UARTs. You don't need to touch
the actual driver source file (`fas.c') to configure FAS. So even
if you wouldn't have the driver source you wouldn't lose any of FAS'
versatility.

It often happens that people think that they have to have a card that
FAS has config files for, or they can't use FAS at all. This is wrong.
All it takes is to edit the `space.c' and `?_fas' files to match the
card's hardware interface. I know that some people aren't experienced
enough to extract the necessary informations from the card's manual,
but with SCO's sio you would have to do the same thing to support a
more exotic card. So this problem isn't unique to FAS.

The main reason for the limited set of config files bundled with FAS
is that I don't want to inflate the size of the distribution by lots
of sample config files for cards that aren't too common.

What I can think of is that a volunteer (not me ;-) collects FAS
config files and puts them in a publicly accessable archive
(hopefully on an FTP server). I would be willing to instruct
the maintainer of the archive on how to change the available
config files in case that the file format changes in a new FAS
release. So, if anyone would like to take over this task, please
step forward.

>  Sure wish FAS run with Linux.

Well, that's another story. While Linux tries hard to be compatible
with UNIX, I suspect that the driver interface in the kernel is not
very similar to the SysV interface. So a port to Linux would be
a major effort. I wish someone would prove to me that I'm wrong,
but I have the distinct feeling I'm not.

So, in short: I can't do this port myself because I don't have the
time, and I don't have the resources. I'd need a dedicated computer
with enough RAM and hard disk to do a port to a different OS (I'm
not willing to give up on the OS I'm currently using), and I'm
not in the mood to spend so much money to do other people a favour
as long as I don't benefit from it myself. I don't plan to use Linux.
So much for an insight into my dilema.

If someone else wants to port FAS to Linux, do it. However, if
there are more than a few changes necessary, I won't include
them into FAS because I can't test them myself. The Linux port
would have to become an independent product with a different
name (the same story as with SASS for SysVr4).

     Uwe
--
Uwe Doering  |  INET : [e-mail]
Berlin       |----------------------------------------------------------------
Germany      |  UUCP : ...!unido!fub!geminix.in-berlin.de!gemini