[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: firmware status for eagle-usb-*



Bernhard R. Link writes:

> * Michael Poole <mdpoole@troilus.org> [041026 19:51]:
> > > The driver contains code to interact with the firmware in operating the
> > > hardware device, just as the program contains code to interact with the
> > > library in performing its function.  The driver does not contain all the
> > > code needed to manage the device; it contains code that can interact
> > > with the firmware.  This particular driver interacts exclusively with
> > > the firmware, not the device (except for handing the firmware to the
> > > device).  The driver is no more complete without the firmware than the
> > > program without the library.
> > 
> > Exactly how does the driver interact with the firmware, except as an
> > opaque blob when sending the firmware to the device?
> 
> And how does a program interact with an library, exacpt as an opaque
> filename given to glibc via dlopen? (What, I am calling things from
> dlsym, what has this to do with the library? it only does not work when
> the library is not there...)

The program explicitly passes control of the virtual processor to the
library for a while, and does not resume execution until the library
returns.  References (usually many references) to specific exports
from the library are embedded in the program.

Operations over an asynchronous medium -- like TCP or PCI -- are quite
different.  The GPL, for example, is very specific about its reach.
We should only use broader definitions than the license(s) with good
reason.

> But even this is irrelevant. If the driver cannot operate the device
> without having to get some data form somewhere else, then it clearly
> depends on this data in every sense of the word. 
> 
> If this data is not includeable, then PLEASE, PLEASE, PLEASE, do not
> promise people what is wrong, namely that the software has no external
> dependencies. (Hint: Placing things in main promises so; as we clearly
> have contrib and non-free to help those of our users that are forced by 
> evil companpanies/beeings/desires to use non-free stuff[1].)

Do you then agree that boot loaders depend on the BIOS, and since
Debian does not include free BIOS software, we must remove boot
loaders (and subsequently everything that depends on them) from
Debian?  We certainly cannot execute much in main without a BIOS, but
we do not find a BIOS in main.

At the least, do you agree that packages which implement only one end
of a protocol must be moved to contrib if nothing in main implements
the other end of that protocol?  For a partial list, see "mass bug
filing for unmet dependencies."

Michael Poole



Reply to: