Re: Ckermit limiting serial speed under Linux ?
On Wed, 10 Apr 1996, Frank da Cruz wrote:
>
> 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 am personally of the opinion that linux should conform to standards
rather than programs conforming to linux - that's how it started out, and
while the linux juggernaut has changed it somewhat, that's still how I
feel it should work.
I'd feel happiest with just something like this:
posix_speed.c:
#include <termios.h>
struct speeds {
long baudrate;
speed_t speed;
} speed[] = {
/* standard speeds */
{ 0, B0 },
{ 50, B50 },
{ 75, B75 },
{ 110, B110 },
{ 134, B134 },
{ 150, B150 },
{ 200, B200 },
{ 300, B300 },
{ 600, B600 },
{ 1200, B1200 },
{ 1800, B1800 },
{ 2400, B2400 },
{ 4800, B4800 },
{ 9600, B9600 },
/* these are "almost" standard */
#ifdef B19200
{ 19200, B19200 },
#endif
#ifdef B38400
{ 38400, B38400 },
#endif
/* extra speeds - add anything here */
#ifdef B12345
{ 12345, B12345 },
#endif
#ifdef B57600
{ 57600, B57600 },
#endif
#ifdef B115200
{ 115200, B115200 },
#endif
#ifdef B230400
{ 230400, B230400 },
#endif
{ -1, B0 }
}
int posix_set_speed(struct termios * ts, long baudrate)
{
.. search for baudrate in "speed[]", use cfset[io]speed ..
}
long posix_get_speed(struct termios *ts)
{
.. use cfgetispeed, search for it in "speed[]" ..
}
and then if the system termios.h header doesn't contain one of the wanted
speeds, you indicate in a comment that the _system_ should be fixed (I
think POSIX should have standardized a way to actually set the speed
directly, not with the Bxxx defines, but that's too late now).
> 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.
I'd really hate linux to be known for it's #ifdef's, so I'd be much
happier with a special "posix_speeds.c" and have a check for POSIX, and
then make the linux distribution use that.
Yes, it would break for people that compile ckermit with older libraries
and header files that don't know the B57600 etc extensions, but they
_deserve_ to break, otherwise they will never get fixed. With linux,
unlike many other systems we can actually fix the problem where it is, so I
think program developers should be even more arrogant with linux (with SCO
you have to accept the fact that not everybody can fix their system).
> 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.
There is still "A" Linux, although the problems you see are probably due
to various growing pains (and the fact that there are different
installations - they are rather similar, but there _are_ some
differences). Within the last half year there has been the move to ELF as
the executable format of choice, and the use of the "ncurses" as the
standard curses library.
Especially with ncurses, some people have been bitten by having the
original curses header files and then a incompatible library (or the
other way around). You might warn about that somewhere. Also, some
distributions still have the old curses (bsd-like) as default, and then
you have to use something like "-I/usr/include/ncurses" and link with
"-lncurses".
Oh, well. I hope we'll get that fixed soon enough.. There is no reason to
use the old curses anywhere any more (or at most have it under the
"bsd-compatibility" stuff).
People who don't have the header files correctly can ask people to make
curses binaries for them.
> 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.
Sure, there are downsides to this. And that's why I feel that you should
ignore requests to make linux extensions that really should be handled in
standard ways, and just help force linux conform rather than throw your
hands up and say "why not, I don't care, they can f*ck up my program all
they want" ;-)
> Sorry for re-including all of the below -- it is for the benefit of the
> extra people that I added to the cc list.
Oops. Some of us don't read mails that way, so I never saw this before I
wrote the above. Doesn't matter.
Anyway, I'd suggest you just do the posix thing for linux, and forward
all complaints to somewhere else (add new Bxxx defines as appropriate:
the non-standard Bxxx stuff is exactly that, and there may be systems out
there with weird speeds - not linux as much as just "posix with extra
speeds").
Forward the complaints to me, even, if you don't have any other options.
But I'd be happier if you just told people to go discuss the library and
header file problems on their own distribution mailing lists (notably RedHat
and Debian who have working lists), and try to get the header files etc
sorted out that way.
Eventually everybody wins - you because people learn, I hope (and
because ckermit will have less of those ugly #ifdef's), and linux because
we'll have a standard system that doesn't get known for weird #ifdef's in
various software packages.
Linus
Reply to: