Date: Sat, 30 Aug 1997 05:52:22 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, julian@whistle.com Cc: bde@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: sio.c "turbo mode" additions. Message-ID: <199708291952.FAA22908@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> Nonstandard speeds break the speed tables in kern/tty_compat.c, >> i386/ibcs2/ibcs2_ioctl.c, i386/linux/linux_ioctl.c, rlogin and >> window (speeds set using termios get corrupted when a program >> saves and "restores" them using sgttyb). You have to extend these >Why should we limit our baud rates to thise used by linux? So that Linux programs work :-). >if we use a standard baud rate (e.g. 9600) they will >still be able to do it right? >I don't see this as much of an argument. certainly >it might be possible to "mask" the baud rates to those that are >expected, but I don't see how removing the table has any bad >effects as the only things looking at that table were in sio.c All Linux termios calls are filtered through the emulator. If you start with speed 230400 and run any termios program that does tcgetattr()+tcsetatr(), then the speed will be corrupted. In fact, due to bugs in the Linux emulator, the whole termios c_cflag will be corrupted - bsd_to_linux_speed() returns -1 (all bits 1) for unsupported speeds, and errors are not checked for, so c_cflag is set to all bits 1. The best that can be done is to mask -1 with LINUX_CBAUD so that only the speed bitfield gets set to all bits 1. Then all unsupported speeds will be set to the "highest" speed. This can be made to mean "don't change the speed" until the bitfield becomes congested again. Currently the following happens: linux_to_bsd_speed() returns -1 for unsupported speeds, and errors are not checked for, so c_ispeed and c_ospeed are set to -1. sio then rejects the whole tcsetattr(). This limits the damage - neither the speed nor the termios c_cflag are actually corrupted. However, this behaviour may actually be a bug - I think tcsetattr() is supposed to set everything it can - it should ignore impossible speeds and use the corrupted c_cflag :-). Note that correct handling wouldn't limit the speeds to ones supported by Linux (except for broken Linux brograms). It would limit the speed to ones supported our Linux (and other) emulators. >There are times when I'd have liked to be able to run at 1500 baud. >I've seen it in some non standard radio gear. >and the console driver allows aby speed to be set >without too much problem.. That's because the console driver doesn't check the i/ospeed at all. It can pretend to handle any speed, but it should handle the magic value of 0. >(sc on my 2.1.laptop anyhow) >I presume that these probrams you mention will only have problems >if I set the baud rate to 1700 or similar. Also for 230400 etc, until the tables are fixed. You can add 230400 and a few higher multiples to the tables, but this will fill up the smaller tables and leave no room for very unusual speeds. OTOH, systems that really need unusual speeds could support them by keeping them in a centralized table. >> >+ int siocn_baud_multiple = 1; /* set from vendor startup code */ >> >> I think this variable is unnecessary - you can use the configured >> value for everything (just be careful about converting the default >> of 0 to 1 everywhere). >no, I want to be able to use this regardless of how available the >com structure values are.. >the siocn-xxx() functions don't have a pointer to the appropriate >devconf or softc structures, so they need a global to use. >I admit that it could easily be initialised from teh devconf struct >at the time that it is probed for the 'CAN BE CONSOLE' bit but >in our case here, we have a file that contains code that >hits soem special registers to double the baud rate. this same >code doubles the multiplier at the same time, so that >the console code always works at the right speed, both before >and after the hardware has been nobbled. Oops, the variable is necessary. It's the initialization to 1 that is unnecessary/bogus. It should be initialized from the flags in all cases. >like a problem to me as it's almost always going to be set to a standard >speed. can you explain this a bit better, and in general Lots of programs (well, shells and editors) both get and set the speed. >do you think that the ability to handle 'turbo' sio ports >(becoming more common these days) is bad or worth while? Worth while. >I would like to re-do the interaction between siocn_xx() and >the normal driver a bit better. but I didn't want to change everything >as I want a HOPE of puting this in 2.2.3 >(where I actually need it) In -current, then main thing missing is support for multiple `siocn' devices. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708291952.FAA22908>