Date: Sun, 10 Aug 1997 23:15:40 -0400 From: "Brian J. McGovern" <mcgovern@spoon.beta.com> To: julian@whistle.com Cc: hackers@freebsd.org Subject: Re: Re: 230+K (was RE: ISDN driver/cards) Message-ID: <199708110315.XAA01742@spoon.beta.com>
next in thread | raw e-mail | index | archive | help
>I have a set of patches for sio.c that use a set of 'flags' bit in the >device flags to specify that the device in question is overclocked >by some multiplier.. The driver then uses different multipliers >so that 9600 still gives 9600 but that new values become >available >e.g. a flags 0f 0x--1----- >where (- == don't care) would tell the driver you are overclocking by >2 (the value of 0 is 1:1 and 15 is overclocking 1:16 ) >so sio.c knows to double the dividers when the above flag is used >so tha the speeds come out right.. > >I will try check it in in the next week or two. > >sio.c is getting too complicated I think...... Perhaps it'd make sense to implement it as an ioctl rather than a flag? That way, a setup-type application can make the ioctl to the initial or lock state device, and "smart" applications can do it to the descriptor that they have open, as well. That way, something like kermit could still use its slow baud rates, but a "control" program could alter say, 50 baud from being 50 baud to 230K, and then back again, without having to change the application. Then, the driver could default to the speed set that makes the most sense, and just about everything would work (getty, kermit, hylafax, etc) without having to be rewired. Or, perhaps it'd make sense to just fix everything to support these higher speeds natively (ie - let 230K be specified in gettytab, etc). Just my two cents worth. It would be nice to have a standard to follow, though. -Brian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708110315.XAA01742>