Re: New iwlwifi 3945 uCode available

[Marcel Holtmann <holtmann@linux.intel.com>]

Hi Tomas,

> >> I do not believe our request is unreasonable. If a user runs a new
> >> kernel the log will print a message that the firmware is incorrect ...
> >> all the user needs to do is go to
> >> http://intellinuxwireless.org/?n=Downloads and download the latest
> >> firmware. This does not require any subtle changes that may affect other
> >> aspects of the system ... just the firmware file that is only used by
> >> the driver.
> >
> > with the wireless that doesn't work.  Nice.  Sorry guys, but requiring
> > a new firmware version for a new driver release is completely
> > unreasonable.  You can drop support for older firmware ABIs after a few
> > years,but not immediately.
> 
> Years.. this HW will be obsolete in year or two, hopefully recycled.
> I personally don't want people using this buggy firmware for years.

seems I have to put clearly my community hat on now.

This is not true at all. I am still using a ipw2100 in one of my
machine. So the 3945 and 4965 will be in use for a long time. The
community measurement of obsolete and companies measurement are totally
different. Also don't forget these countries where laptops and
electronics are still expensive. The old Intel wireless cards will still
be used for a long time there.

> This is development branch after all, it's not even scheduled for 2.6.28.
> 
> Ucode API for 4965 was changed to -2 without much pain, So there is a
> precedence this work quite well. This time there were some hiccups in
> handling this since the API version wasn't updated it as should be.
> really our fault. But I don't think this situation is so dramatic as
> you describe it.

Actually that is your impression. I was falling over the 4965 ucode API
change twice and it took me longer than 5 minutes to even debug and
understand what went wrong here. Since there is no real warning anywhere
and the wireless device does show up. And I do know how to handle these
things.

> The objective of the objections is not that we want to immensely hurt
> users but rather the trade off between maintain even uglier code and
> users running buggy firmware versus logging into older kernel and
> downloading new firmware in 5 minutes looks to me not proportional.
> Distro users that pull updates won't even notice. I might be wrong
> though.

There will be cases where it is too much of a burden and too complicated
to keep support for both APIs, but in all other cases we should try to
have the driver work with it. I am fully behind Johannes and Christoph
here since that is what the community expects.

So if we ran into a case where we need to abandon the support for the
old API, then we first should make sure that the modules_install will
warn loudly about the missing firmware. And with MODULE_FIRMWARE and the
firmware work from David, we do have everything in place to actually do
this. So lets do it.

An additional option would be to create drivers/deprecated/ and put a
copy of the old driver there and have some Kconfig magic to allow
selecting only one of the drivers.

Regards

Marcel