> On the question of whether this is nothing more than
> aggregation,
Yes, on that very question, I would argue it is a mere aggregation.
> the firmware works intimately with the device driver to
> produce a unitary result.
Irrelevant. All drivers work with some sort of firmware on their respective
targets to produce a unitary result, even if that firmware is implemented with
silicon (as a ROM BIOS that loads the proper firmware code, or as
microcode/state hardware built into the chip(set) itself). As a closely
similar device, think about the 1542 SCSI controller. It has a BIOS that must
load firmware before the card will work. The only difference between it and
the device you are arguing about is *how* the firmware gets loaded, and by
what program, not whether the firmware gets loaded or whether the firmware is
required for the device to be in the least bit usefull as a computer
component.
> The part of the driver that runs in the
> device and the CPU side speak a mutually agreed upon protocol, and the
> unitary result is that you do not have to preload the firmware as
> earlier versions of the driver required.
Again, irrelevant. This has always been done. In the past, it was done by a
user land program. Now it's done as part of the kernel. So, the code now
knows how to speak "load the firmware" language to the chipset. This is a
feature of the driver that is, in fact, not in the least bit related to the
firmware itself. The driver could load garbage to the device and this code
would be working properly. The choice of what data to upload to a device is
distinctly different from the ability to upload data.
> You actually have to do some
> kernel development to remove the code.
That's because you are assuming that uploading garbage to the device is not an
option. This is incorrect. You can in fact remove the firmware and upload
garbage. The result would be that the device would not work as expected.
Would this be because of a bug in the firmware loading code? No. It would be
because you uploaded garbage. You could likewise make a much smaller
modification to the driver so that it would allow you to specify whether or
not to upload the code, then tell it not to upload the code, and preload the
firmware as before and things would work without removing the ability to
upload code from the driver. You could also modify the driver to pass the
firmware to the driver via an initrd or some such and have this code work
without having the .h file included in the .o archive.
> It's not simply the case that
> you could just skip distribution of an extra file and have the rest of
> the functionality work.
That is exactly the case. The only change that must be made to remove that .h
file from the driver source is to tell the driver where the *new* location of
the correct firmware is. This does not constitute a dependancy on having the
firmware included in the driver, it merely constitutes a hard coded, expected
location of the firmware that must be updated whenever the firmware is moved.
> In fact, even if you zeroed out the
> microcode, you would still not get the result of having the driver
> work (e.g., if you had loaded the code originally). Instead, the
> driver would fill the device with all zeroes.
And thank you for making my point. The upload code would in fact work, it
would just upload a bogus firmware. Bad data is bad data. However, stating
that providing a driver with bad data makes it fail is a non-issue and proves
nothing. I could write all 0's to the PCI bridge in my system and it wouldn't
work properly. Duhhhh.....who would expect it to?
> Greg Kroah-Hartman has
> already said he thinks removal is complicated enough that he does not
> want to voluntarily do it in 2.4.
Aka, he doesn't want to correct/work around the fact that the driver has the
location of the firmware data hard coded right now. He doesn't have to remove
all the upload code to remove the firmware file, he merely has to teach the
driver to find the firmware code elsewhere or to not upload garbage when it
doesn't know where the firmware is.
> For these reasons, this situation
> is not just shipping two works next to each other (mere aggregation).
Your reasons are bogus, it's a mere aggregation.
> I hope it should be clear now that the GPL can and does
> prohibit #include'ing this and that it is not mere aggregation.
>
> I also hope that people understand that while I think the
> stability argument for not including my fix in 2.4 (which everyone
> seems to like technically) is BS, I would be satisfied if the
> keyspan_usa drivers were now released under GPL-compatible copying
> conditions. However, it has now been weeks this has not been done.
>
> Adam J. Richter __ ______________ 4880 Stevens Creek Blvd, Suite 104
> adam@yggdrasil.com \ / San Jose, California 95129-1034
> +1 408 261-6630 | g g d r a s i l United States of America
> fax +1 408 261-6631 "Free Software For The Rest Of Us."
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--Doug Ledford <dledford@redhat.com> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/