[3319] in linux-net channel archive
Re: Binary Driver Issues
daemon@ATHENA.MIT.EDU (Dennis)
Tue Jun 18 23:18:55 1996
Date: Tue, 18 Jun 1996 15:14:12 -0400
To: Mike Kilburn <mike@lserv.conexio.co.za>
From: dennis@etinc.com (Dennis)
Cc: linux-net@vger.rutgers.edu
>
>
>On Tue, 18 Jun 1996, Doug Ledford wrote:
>
>> about. ET could do the same thing. Allow a driver for their card in linux.
>> Don't include the bandwidth management features and such with that driver.
>> Allow the basic Frame Relay driver in 2.0.0 to be the higher layer to their
>> card. Then, if someone wanted the full functionality of their current driver
>> they could buy the enhancement module in binary only form from ET. This
module
>> could be made in such a way that it interfaces with the card driver in a
static
>> fasion so that kernel upgrades and version changes would not effect it. I
>> would see this as a perfectly acceptable solution to the problem. It would
>> protect the intellectual property of ET, while at the same time providing a
>> basic driver for linux, and giving source for the basic driver so that it
could
>> grow and change with changes in the kernel structures.
>
>But what I am saying is the opposite. The low level board driver can
>be binary only since that is an extension of the firmware (or lack of)
>for the card. While the "value-added" kernel enhancements should require
>source. I know this will never happen with ET. But *new* companies can
>plan from the start to make a profit and be free.
>
Why is a driver that limits traffic through only that device a kernel
enhancement?
I think maybe you dont know what you're talking about.
db
