Re: Preparing linux-2.6 2.6.18-1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sven Luther wrote:
> The reality is not that the kernel team don't want those firmware in main, but
> that in the current state of the debian technology, it is not feasible to do
> it right, and it will take time, and will be best done during the etch+1
> development cycle.
>
>> (In some cases, nonexistent users. drivers/net/dgrs "was killed in place
>> and never reached the market". No users were impacted by removing this
>> driver, and we know that for a fact. Why readd it?)
>
> Because it is a pain to remove them ?
Try looking at the X.org packages: they have a fairly simple
prune-non-free system.
<snip>
> Upstream is making progress, see the qlogic firmware for example, and the
> debian kernel team, which is the one who will be making this work, not the
> release team, has a strict policy of following upstream closely, in part
> because we don't have the ressources and work-force to maintain a huge set of
> forked patches.
See below. I'm afraid we can't trust upstream to fix everything. Some
driver and subsystem maintainers are quite aggressive about fixing this
stuff. Some....not so much.
>> A good start would be the tg3 patches. Reintroducing the dgrs driver,
>> which drives *no existing hardware at all*, would be a very bad move.
>
> So, you dismiss the qlogic firmware out of hand ?
No, it's good stuff. Thanks to whoever did this upstream!
> tg3 may follow, if there is
> a good enough patch to do it nicely. This may come, either from someone like
> you (but the patch has to be upstream-quality, which apparently your patch was
> not),
Yes, it was upstream-quality. (Although to be honest the *driver* is
pretty ugly stuff.) There was one bug spotted by Herbert Xu and fixed
by him.
Upstream was a couple of people who at the time of last submission had a
marked hostility to all userland firmware loading, of any quality. This
may have changed.
The patch is difficult to maintain because the *entire driver* must be
removed and replaced -- this is because upstream refuses to separate the
firmware into a separate file.
At the time of previous submission, I suddenly realized -- after testing
was done -- that distribution of the firmware was not legally safe, and
I stopped doing it.
This meant that the firmware-loading code lay unused, obviously causing
complaints from those few people who needed the firmware. It also meant
that I could not satisfy the transition requirements which were
requested by upstream, which were to include the firmware in the hex
blobs in the driver *and* have userland firmware loading simultaneously.
I have asked more recently whether this transition scheme is still
desired, with no answer.
Thank goodness the firmware license has been fixed now.
These are the reasons the patch is not upstream: note that the only
technical one is the transition scheme request. I will try again and
see what happens.
> or from the kernel team. tg3 is not the only case of such though, is it
> emblematic to you because you provided a patch when Herbert was still around ?
Yep. And for the following other reasons:
* because the patch was accepted and later retracted.
* because I'm not aware of fully functional patches for any of the other
cases. (My radeon and r128 patches don't work properly, FYI.)
* because it represents a case where, given upstream's previous
behavior, Debian may very well *have* to apply the fix itself, even if
Debian wants to track upstream closely.
* because users don't lose any hardware support if it's applied now
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFF6eKRGZ0aC4lkIIRAsbCAJ9z1XvUPo9blgLIE4a4bKF0hD1qDwCdGR+H
Kmd6BOs/J7Z0hST2Oee/M6A=
=K8N2
-----END PGP SIGNATURE-----
Reply to: