Re: Anyone ported HCF/HSF modem drivers to FreeBSD?

Daniel O'Connor wrote:
> On Monday 01 September 2003 08:41, Mark Kettenis wrote:
> >    I asked this on -hackers a little while ago but no response.  I'm
> > curious if anyone has made an attempt to port these Winmodem drivers.
> >    http://www.linuxant.com/drivers/
> >
> > I did look into it, but concluded that it was pretty hopeless.  For
> > starters, the DSP routines in there seem to need the FPU, and FreeBSD
> > doesn't seem to allow that in the kernel.  Apart from that, almost
> 
> I don't think that would be _that_ hard to fix at least for that specific
> driver, but I'm not 100% sure.

I ported the HCF driver for use on my Sony VAIO, a while back,
and the author of the thing was kind enough to compile it as
PIC so that I could load it as a kernel module.

The FPU stuff is pretty embedded; without disassembling, changing,
and reassembling the code, which is prohibited by the license,
there's really no way to yank the FPU stuff out.  So you have to
change the lazy FPU context switching, to enable use of the FPU
inside the kernel.  Which really blows, on many levels.


> > 100% of the code is in the binary-only modules, including a lot of
> > Linux-specific code, which makes it very hard to see how the code is
> > supposed to interface with the kernel.
> 
> Have you seen these drivers ->
> http://www.smlink.com/main/index1.php?ln=en&main_id=32

No good for the HCF modems.


> And the binary code appears to only call shim routines for which the source is
> available.

The HCF drivers have threading and timer code dependencies.  They
also have an expectation of being able to import symbols from the
Linux kernel (though most of them actually use a jump-table via a
registration function that you pass a structure to).

The main problem I ran into was the FPU code; the next main problem
was the PIC code (as I said, though, the author was willing to go
PIC on the code, and I believe that's still how it's now distributed
for Linux).  The next main problem was emulating enough of the Linux
kernel environment to pass glue functions down to the modem (and the
big mess there was interval timers -- the driver tends to use a lot
of CPU time).

I would really recommend what I ended up doing, which is leaving the
FPU code along and using a real modem in a PCMCIA slot, instead.

-- Terry