Re: Ckermit limiting serial speed under 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.
This kludge is no longer needed.
I will fix the code over the weekend I hope.
I also consider changing the Digiboard driver to support the ioctl call
that it is not supporting right now (and the reason it fails for 38400
and above),
which seems to be used only to see if 38400 should be mapped to spd_hi or
spd_vhi.
>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.
It is the ASYNC_SPD_MASK that is guilty. It is in some of the "normal"
headers.
>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.
Nope. But always defined if you have non-ancient headers.
>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.
I will modify the code to do it the real way, especially as I can not get
the
kludges to work with my digiboard. uugetty also has a problem, even
though I tried
to use EXTB as speed for 115k in /etc/gettydefs.
Guess I have work to do there as well.
>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.
But, one single Linux method should be enough. The current code should be
changed to
#ifdef ANCIENT_LINUX :-)
>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") }"?
It is moving this way, as people only upgrade parts, and there are a few
distributions compiled with different flags to expect files in different
places.
But, Linux is also not that bad when it comes to source compatibility.
And it
runs on lots of hardware (PC, soon Macintosh and other on Mach kernel,
Sun,
Digital Alpha etc.).
>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?
There is still just one kernel. But some people include some features
others don't want. It is a customized kernel on each machine.
>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.)
I think I found kermit on my Slackware CD. But I am not sure.
Debian tries to be a more closed system, or rather to stand out from the
others.
But I don't think they have that much market share. Slackware can be
downloaded
completely - which is not the case with Debian.
Reply to: