[Gllug] Anyone having broadband (probably PlusNet) problems today?

[Russell Howe]

On Thu, Mar 24, 2005 at 08:49:05PM +0000, Ian Norton wrote:
> On Thu, Mar 24, 2005 at 12:22:06AM +0000, Russell Howe wrote:
> > On Thu, Mar 24, 2005 at 12:04:00AM +0000, Chris Bell wrote:
> > > Another way would be to use a PCI modem in the firewall box.
> > 
> > Yes, this is an option, although there seem to exist no such devices
> > with open source drivers.
> 
> The drivers for the connexant based pci modems arent fully opensource, (it has
> firmware it uploads to the ARM on the modem afaik) but I've had it
> running perfectly fine for about 4 months, it needs a redial occasionally but
> that could just be my local loop,

Disclaimer: There are many people on the 'net (and probably on this
list) who know more about this than me. Still, I just got back from a
weekend without IP connectivity and I feel the need to send a large
email to a mailing list.

I would be suprised if the binary part is firmware uploaded to the card.
I suspect it is binary code which is loaded into your kernel and
executed there. That's what things like the Unicorn drivers do (for the
Bewan cards), the nvidia closed-source drivers and the Atheros
802.11a/b/g madwifi drivers do.

The madwifi driver only loads a small binary chunk, apparently, which is
to do with setting power and frequency output of the card - their
argument is that they can't opensource it due to FCC regulations.
Doesn't matter now - the OpenBSD folks have kindly reverse-engineered
it, and so has someone else, according to a posting on lkml.

Compare this to some other devices (RAID cards? I don't know) which
actually have a microprocessor onboard, and whose drivers upload binary
firmware on startup in order that the hardware is usable. This code runs
on the hardware itself and not as part of the operating system.

There is a big difference between the two - binary code running as part
of your kernel can do pretty much anything e.g. corrupt your hard drive,
open a listening network port, allow compromises or, more likely, just
be generally unstable and poorly written. As they're closed source
you're relying on a closed community to provide a decent bit of
software.

Contrast this with firmware, which doesn't share the kernel's address
space and which interacts with the kernel over a well-defined interface
(e.g. the PCI bus or USB). Sure, if the hardware of the card is capable,
the firmware can do bad things, including data corruption, crashing
(although only that piece of hardware would crash), DoS'ing the bus the
hardware's connected to, perhaps, etc, but the scope of the harm caused
is much more limited and outside of the OS's control, typically. Any
vendor producing such firmware is unlikely to be very highly regarded!

The distinction between binary drivers and binary firmware
(s/binary/closed source/g, if you wish) is a big one, and an important
one. The moment you load binary code into a GPL kernel (and please,
someone, correct me if I'm wrong here), you are no longer running free
software, and you cannot (under the terms of the GPL) redistribute that
modified kernel, withough including the source for the changes you made,
which you of course don't have, as you mixed it with a binary module.

This is why you won't see any distributions with the nvidia module
provided 'out of the box' as it were, or if you do, those distributions
will have to be very careful with their method of bundling the binary
code.

PS - I don't mean to suggest that you don't know the above, but I think
it's a point of interest within the open source community at present
(closed source drivers are now in common use, as is closed source
firmware), and it might be of interest to someone, somewhere.

-- 
Russell Howe       | Why be just another cog in the machine,
rhowe at siksai.co.uk | when you can be the spanner in the works?
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug