The Linux kernel STRIP module was updated to support the newer series of Ricochet modems in January of 2002 by a person about whom I can find nothing more than a username of `abelits'. Anyway, he wasn't smart about it and didn't submit his patch to the LKML. When the existing drivers were migrated to the 2.6 tree, the old version of the module was migrated, and that's where the problems began.
`abelits' provides a patch for 2.4.1, though it applies cleanly to the recent 2.4 kernels with just a little fuzz. However, the 2.6 version of strip.c is significantly different from the 2.4 version. Most structures in the diff are easy enough to find in the new version of the source, so I tried hand-merging the differences. Unfortunately, given my limited knowledge of C, I wasn't able to get anywhere with it.
I attached copy of the patch and the link to the source of the patch's origin in the hopes that someone can migrate this driver to the current source tree and possibly merge it into both 2.4 and 2.6 production kernels. I can UPS a modem to someone if that's the real problem. If this idea is feasible at all, please reply.
http://mars.illtel.denver.co.us/~abelits/metricom/
Look near the bottom, section 8.4.
--
I am not on the list, please CC replies to me.
On Sat, Jan 08, 2005 at 05:45:25PM -0800, Michael Ryan wrote:
> The Linux kernel STRIP module was updated to support the newer series of
> Ricochet modems in January of 2002 by a person about whom I can find
> nothing more than a username of `abelits'. Anyway, he wasn't smart about
> it and didn't submit his patch to the LKML. When the existing drivers
> were migrated to the 2.6 tree, the old version of the module was migrated,
> and that's where the problems began.
strip also has other problems - it violates the layering of the kernel
subsystems and drivers in the get_baud() function:
if ((tty->termios->c_cflag & CBAUD) == B38400 && tty->driver_data) {
struct async_struct *info =
(struct async_struct *) tty->driver_data; /* XXX */
if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_HI)
return (B57600);
if ((info->flags & ASYNC_SPD_MASK) == ASYNC_SPD_VHI)
return (B115200);
There is no guarantee what tty->driver_data points at, and in fact
today the above code will be broken.
The best thing to happen here is to ignore the B38400 "hack" for fast
baud rates, and use the helper functions in the tty layer to get the
_numeric_ baud rate, which seems to be what the driver wants anyway:
/* If the user has selected a baud rate above 38.4 see what magic we have to do */
if (strip_info->user_baud > B38400) {
So, I don't think that this patch will be sufficient to resurect strip,
but I also don't think that it's an impossible task. I'm just wondering
if it's really worth the effort given that we now have the vastly more
popular 802.11.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core