You are mistaken, and you're responding some words that someone _else_
put in my mouth.
That's easy enough. We can automatically generate a tree _from_ Linus'
tree, with a scripted transform so that it includes only the firmware
files (much like the kernel-headers tree automatically follows each
commit in Linus' tree, but includes only the exported headers).
And there are some hardware manufacturers who are willing to have their
firmware included in such a firmware tarball, but who will _not_ give
their permission to have it included in the Linux kernel because of the
legal concerns you're so dismissive of. But that's OK -- we can pull
from the automatically generated tree into a 'real' linux-firmware.git
tree, which includes those extra firmware files.
But there's no need to do it _now_. It can wait until the basic stuff is
in Linus' tree and it can automatically derive from that. There's no
particular rush, is there?
> both in the kernel source tarball as well as separately
That makes a certain amount of sense.
Please don't be gratuitously offensive, Ted. It's not polite, and it's
not a particularly good debating technique either. I expect better from you.
> are trying to decouple firmware from the kernel sources.
The distros are certainly willing (and keen) to do it. The Fedora
Engineering Steering Committee has already stated that it wants to do
so, and the specfile changes to spit out a 'kernel-firmware' sub-package
with the kernel build are ready to go right now.
Fedora already modifies tarballs, for example 'openssh-5.0p1-noacss'. I
think it's quite likely they'd end up using a 'linux-2.6.27-nofirmware'
tarball too, and build the firmware package from the separate tree.
Some other distributions have been doing that kind of thing _already_,
even when it meant just ripping out certain drivers completely. That
seems excessive to me; I prefer not to actually _break_ anything.
> and firmware release levels, that will also give people a chance to
> get that all right. Then 6-9 months later, we can turn the default
> about removing the firmware modules.
I disagree that the _default_ is such an issue -- largely because the
normal case for modern drivers is not to include the firmware _anyway_,
and the tools like 'mkinitrd' already cope with it just fine.
But I've changed the default to 'y' now, as I already said.
--
dwmw2
--
