Re: Ckermit limiting serial speed under Linux ?
Hey, I'm only one guy trying to support C-Kermit on about 500 different UNIX
variations, not to mention VMS, OS/2, VOS, AOS/VS, etc etc, and it's more than
a little bit hard to keep up with the rate of change out there.
Several years ago, the biggest thorn in my side was the SCO operating systems.
Things would change and move and disappear out from under Kermit at an amazing
rate. But now I think the award has to go to Linux.
The way Kermit supports high serial speeds in Linux is by using <serial.h>,
and enabling the high-speed keywords ("38400", "57600", etc) when the program
is built with -DLINUXHISPEED, as it always is (unless you include -DNOHISPEED
among the CFLAGS) -- Search for LINUXHISPEED in ckutio.c and ckcdeb.h.
But wait, there's more. Now search for ASYNC_SPD_MASK in ckutio.c to see
some real trickery. Don't ask me to explain it -- it was sent in by a
hard-core Linux programmer a couple years ago. Maybe this code has become
dated. Of course, no code every really becomes dated since we all know that
there are plenty of people out there still running Linux 0.9x who would scream
bloody murder if we took it out.
On the bright side, however, this code only gets included if you define this
symbol. In the makefile entries that are provided, it is not defined.
So now do we need another avalanche of #ifdefs to support newer methods of
getting high speeds? And perhaps yet another that is special just for
Digiboards? If so, by all means send in the code.
Bear in mind that anything having to with a speed higher than 9600 is not
portable across UNIX versions, and C-Kermit must support *all* UNIX versions.
When you look at ttgspd() and ttsspd() in ckutio.c, you'll probably need
special glasses to cope with all the #ifdefs.
Also consider how any new code is to be tested on all the many, many, many
Linux versions, packages, libraries, etc. A rhetorical question -- what else
can we do but just turn it loose and wait for the screams of agony.
On an epistimological note... Is there still "A" Linux? Or is Linux today
what "UNIX" used to be (and still is) -- a panoply of incompatible variants on
an original theme, whose claim to portability can only extend to "main() {
printf("Hello world\n") }"? Sorry, I don't mean to be cynical, but recently
I've been getting scads of reports from Linux users claiming that Kermit core
dumps if they do the simplest little thing, like type two innocuous commands.
Is there still just one kernel for each release, or do different packagers
build different kernels? How many different and incompatible C libraries are
there for Linux? How many different companies or groups are putting together
Linux distributions? One of my favorite complaints is from people who want to
use the full-screen (curses) file transfer display and the program dumps core.
If they are using libcurses, then the solution is to link with libncurses
instead. And (would you believe) vice versa. More recently, some people are
complaining that anything to do with a serial port ("let line /dev/blah")
core-dumps, where other people, running what they say is the same version of
Kermit on the same version on Linux, say it works fine.
The Debian Project has been kind enough to stay on top of this stuff for
their distribution, but I haven't had much contact with the other Linux
distributors -- mainly because they are upset that I don't want them putting
Kermit on the CDROMs that they sell. (The Debian Project does it right, for
which I'm grateful -- they put together a Debian-format C-Kermit package, but
let *us* distribute it.)
Again, still being cynical, unless I have a badly distorted picture of the
situation, it seems to me that the much heralded benefits of Linux -- the GNU
vision of a free UNIX for all -- has dissolved into chaos because of a lack
of centralization and control. Now I'm as much of an anarchist as the next
guy, but sometimes centralized control is a good thing. It is much easier for
me to deal with, say HP-UX 10.0 than it is to deal with (what seems to me to
be) the amorphous blob that Linux has become.
Sorry for re-including all of the below -- it is for the benefit of the
extra people that I added to the cc list.
(I must be in a bad mood today... Maybe it's because I'm trying to get a
new release of C-Kermit out the door and every time I think it's ready to go
I get another message like this one...)
- Frank
> > >I can NOT go above 19200 in kermit on /dev/ttyd0. But can
> > >go all the way to 115200 on /dev/ttyS0.
> > >
> > >Kermit tells me the baud rate is not supported on the
> > >device. I would like to know where this rate is specified,
> > >as ditty allows me to set the rate higher.
> >
> > .. as anyone can do using, for example, termios calls.
> > Actually, it works fine - this at least I know for a fact.
>
> I have the same problem with Ckermit 5A(190) under Redhat Linux (RHCL v2.0):
> I can set the speed on a modem to 9600, 19200, 38400, 57600 & 115200 if it
> is connected to a standard com port (eg. /dev/cua1) *but* if the modem is
> on a Digi port, I can only set the speed up to 19200. Speeds of 38400 and
> greater produce the error "Unsupported line speed - 38400".
>
> >
> > I guess the real problem here is "why is kermit saying what
> > it is saying?". I'm not sure how it distinguishes one port
> > type from another, since I surely do not know. Since kermit
> > may have some Linux-specific code here, perhaps it is making
> > assumptions based on the device numbers (a guess). But this
> > still remains back in your kermit package's court to answer,
> > since no matter what - if any - problems exist in the
> > Digiboard driver, there is no way we can fix the assumptions
> > that package is making.
> >
> > >I don=B0t have any kermit source, but it could of course be
> > >this program that will not do high speeds on anything but
> > >cua and ttyS devices, but I think there is another factor
> > >causing it.
> >
> > My guess is that it contains some Linux-specific code and it
> > may indeed be looking for major device '4', and won't
> > support the high-speed settings otherwise. I can't see any
> > justification for this approach, but perhaps the author had
> > his/her reasons.
> >
> > Can the source code for kermit be obtained, or at least the
> > author put in touch with us/me so we can discuss it and
> > resolve the problem? AFAIK, most if not all third-party SIO
> > drivers for Linux do indeed support the full range of baud
> > rates that Linux provides, so the need for special handling
> > (assuming there is any) is entirely counter-productive.
> >
> > Regards,
> > David
> >
> > David Nugent, Microsystems Technical Support
> > Unique Computing Pty Limited, Melbourne, Australia
> > PC/LAN/UNIX Communications Software Development
>
> I've looked at the Ckermit source (available from kermit.columbia.edu) for
> both Ckermit 5A(190) and for Ckermit 5A(192) Beta.16. The failure seems to
> originate in ckutio.c in function ttsspd() (set speed). Ckermit is doing a
> tcgetattr() which returns -1 for speeds of 38400 and greater on a Digi port.
>
> Now, it seems to me that this is a problem with the Digi driver. I've tried
> looking at /usr/src/linux/drivers/char/pcxx.c, without success. Perhaps
> those with more experience with the Digi driver may find this information
> useful.
>
> --
> Thomas J. Pinkl (tom@hbsrx.com)
>
Reply to: