Subject: Re: You have to start somewhere....
From: Jeff Garzik <>
Date: Tue, 8 Jun 1999 02:26:03 -0400 (EDT)
Tue, 8 Jun 1999 02:26:03 -0400 (EDT)
On Tue, 8 Jun 1999, Dean Beeler wrote:
>     Sorry about posting a binary to the discussion group, but
> considering the response, I figured everyone would want to see the
> starting point for my LinModem project.

Maybe talk to the admin of about getting some mechanism to
post it on that Web site.

>     Someone said something to the effect that VxDs run in Ring 0 which
> is why they won't work in Linux.
> This may be true, and we will
> certainly find out how much freedom is needed once we start trying to
> initialize the VxDs using kernel level threads.

That's a bunch of baloney.  Ring 0 is fancy speak for talking directly
to the hardware.  You don't even need a kernel driver to talk directly
to the hardware. (XFree86 talks directly to your video card, and it is
100% userland)

In any case, here are my two cents.

I really think that a userland daemon is the best design for WinSand.

This daemon would serve as the VxD manager for the entire machine.  It
would be responsible for loading, unloading, and emulating each VxD.
Each VxD should be a child process, for safety and cleanliness.
Threads won't buy you much that SysV shared memory and semaphore can't

You would need only a tiny, generic kernel device driver to "hook" into
the kernel serial driver, or SCSI driver, or whatever type of driver you
are emulating.

> Kernel level threads
> are also what Wine uses to run its Windows executables as well.

It uses kernel threads, not kernel level threads.  Gtk+ uses kernel
threads, knfsd uses kernel level threads.

> I've been thinking... ok... how hard is it to control these DSPs in
> hardware anyway?   Besides sheer CPU power, all you are doing is simply
> IRQ requests, I/O accesses and Co-processor use.

Not hard at all.  I/O accesses are easy; you probably need a kernel
device driver to send signals or something when interrupts occur.  The
VxD tells you what hardware to talk to, and how to talk to it.  You
just have to implement the generic mechanisms.

You may wind up having to internalize a system VxD in order to provide
a subsystem.  For example, I believe there is a generic serial driver
layer (VCOMM.VXD?) which all serial drivers talk to.  You would need to
implement those functions in WinSand, since you must translate its
functionality such that it talks to the Linux not Windows serial

>     Finally, if someone could tell me about the driver configuration for
> these seemingly popular Lucent WinModems so I could get some idea how
> uniform the whole VxD/WinModem is between developers.

You can find a good overview of the Lucent card at

There is no hard info on these chips publicly available, but if you are
really diligent in browsing their tech docs section, you can pick up a
lot of info that is "possibly useful."

Tech docs:

The most useful things, IMHO, are the tech docs not the files.  There
are bits and pieces of descriptions of the various DSP16xx chips, which
Mr. Ed Schulz from Lucent kindly confirmed was the same core instruction
set as that on the Lucent winmodems.

The winmodems have a DSP164x chip, and there is an instruction set
reference for a DSP1620 chip.  The winmodems have a CSPxxxx codec, and
there is a tech doc describing a codec with a slightly earlier
model number.  You can pick up little details like this.  There is also
an SDK you can download for DSP16XX chips, it may be useful, maybe
not.  All of the provided source code requires a special microcode
assembler which I didn't find.

Finally, there seems to be some sort of microcode that gets loaded onto
the card, though I don't know when or why this happens.  There is some
RAM on the card apparently.