[svlug] Expectations for Windows XP and Linux

[Rick Moen]

Quoting Tom Pilot (hman_120 at yahoo.com):

> forgive my ignorance but is that process something that is already in
> place, say in ubuntu 6 or is it just your idea of solving the problem?

Nothing to apologise for.  ;->

The pieces I spoke of are already there, so that's good news.  As a
result, things should Just Work for wifi chipsets that were known and
had shipping (and included) driver as of your installation kernel.  For 
already installed systems (by contrast), you happily are not limited
just to hardware supported as of your distro's code freeze, because you
typically update, from official package updates a few times, the kernel
+ kernel modules, the printer filters ("printer drivers"), and your
video-hardware-specific X11 server modules ("video drivers") over the
life of your system load.

A few thoughts on the pieces involved:  This is getting a bit ahead of
my planned write-up on the Atheros situation, so pardon me if this is a
bit compressed and not fully formed.  (I also know that this is way
beyond what you were asking about, Tom, but I'm writing to the attention
of other readers, as well.)


To my knowledge, all of the second generation (and later) of wifi chips
economise on parts cost, compared to first-generation chips like those
in my old Lucent Orinoco and Cisco Aironet cards, by omitting the option
ROM chips, and instead providing a binary firmware image _file_ that is
intended to be loaded into the card's memory at initialisation.  The
firms in question, e.g., Intersil, Intel, Broadcom, Atheros, etc., as
noted, tend to completely ignore the Linux market and instead merely
produce Windows drivers that, among other things, furnish this firmware
file.  The bundle of all of those files is furnished to Microsoft and
other business partners for distribution by authorised distribution
sites and on business partners' "driver disks" given out to the public, 
etc.

...which brings those files to the attention of the Linux community, who
in some cases are able to figure out "Oh, just lob this firmware image
file into RAM in the obvious fashion like _so_, and you've initialised
the hardware."  If the manufacturer has designed that firmware image
correctly, the lobbing-into-RAM process is OS-neutral, and, once the 
Linux community coder has written the driver _proper_, the device works
as a network interface in Linux.

...with the minor glitch that the firmware image file cannot lawfully be
included in Linux distributions, because the hardware manufacturer never
gave the public redistribution rights, which are reserved to the
copyright owner by default.  This is the situation (IIRC) with Intersil
Prism GT/Duette and Intel Pro/Wireless 2100 "Centrino" chips, for
example:  Linux distros include robust and functional drivers, but you
the user must separately fetch the firmware files and put them into
/lib/hotplug/firmware/ -- because the manufacturers have neglected to
issue redistribution permission.

It's my contention that, except for the regrettable lack of
redistribution rights, _this_ sort of binary firmware image file is OK
and raises no significant open source questions.  Why?  Because it's
limited to OS-neutral initialisation code, exactly like the ROM contents
in my Lucent and Cisco cards.  We don't grumble about that code when
it's in a ROM; why should we object more when it's loaded from a file?


If I understand the Atheros situation correctly, they've issued a binary
"blob" that isn't limited to _just_ ROM-equivalent functionality, and
therefore is not at all OS-neutral, thus making the pseudo-open-source
Linux driver solution ("Madwifi") hostage to future CPU platform and
kernel changes, like other proprietary code.