b43-fwcutter: add helper script for getting firmware

b43-fwcutter: add helper script for getting firmware

[Rafał Miłecki]

Hey,

Installing a firmware was always kind of challenge for end users.
There were many tries of solving this:
1) Distribution wiki pages with descriptions
2) b43 wiki page trying to handle the most common distros
3) Extra non-free packages
4) Scripts like install_bcm43xx_firmware in openSUSE
5) Scripts like postinst in Debian
Way too many of them. Way too complex.

My idea is to add a helper script to the b43-tools / fwcutter and put
it during install in $(PREFIX)/bin/. This way we will know that every
user who installed b43-fwcutter also owns our script. Then we just
tell our users "hey, fire your b43_install_firmware" (or whatever).

Of course distros still we be able to make it automatic. For example
Debian's postinst could simply call this script and simplify its
postinst. Same for RPMs.

[The second part]

Now, if you like my idea above, there is one more thing worth
considering. Offline firmware installation. It's not that common, but
there still appear ppl who can't use Ethernet cable and don't have
another Linux machine to extract firmware using it. For them our
script would be useless.

So my another idea is to make our script accept passing path to the
driver as a command line argument. So one can download
broadcom-wl-6.30.163.46.tar.bz2, put it on a USB flash and call
b43_install_firmware /mnt/usb/broadcom-wl-6.30.163.46.tar.bz2
We should also remember to allows passing other archives as an
argument (wl_apsta-3.130.20.0.o at least!).


Do you like this idea? Could someone handle this?

-- 
Rafa?

b43-fwcutter: add helper script for getting firmware

[Michael Büsch]

On Fri, 1 Aug 2014 19:41:57 +0200
Rafa? Mi?ecki <zajec5@gmail.com> wrote:

> Installing a firmware was always kind of challenge for end users.

Yes, agreed.

> There were many tries of solving this:
> 1) Distribution wiki pages with descriptions
> 2) b43 wiki page trying to handle the most common distros

a) We have this (in a generic way).
b) Nobody (tm) reads this.

c) Not so surprising :D

> 3) Extra non-free packages

Distros do this. I don't see me getting involved here.

> 4) Scripts like install_bcm43xx_firmware in openSUSE
> 5) Scripts like postinst in Debian
> Way too many of them. Way too complex.
> 
> My idea is to add a helper script to the b43-tools / fwcutter and put
> it during install in $(PREFIX)/bin/. This way we will know that every
> user who installed b43-fwcutter also owns our script. Then we just
> tell our users "hey, fire your b43_install_firmware" (or whatever).
> 
> Of course distros still we be able to make it automatic. For example
> Debian's postinst could simply call this script and simplify its
> postinst. Same for RPMs.

Ok this sounds good. _But_ I am not a distribution guy.
We should probably contact the Debian, Fedora, SuSE or whatever package
maintainer to get comments on this.
It would be bad, if we ship something, that turns out to be useless for
distro packages, for whatever reason.

I already integrated some patches from the Debian package recently and
I am all for getting distro specific stuff upstream. But we should
collaborate with the distro maintainers. (And so should they and send all
their patches upstream)

> Now, if you like my idea above, there is one more thing worth
> considering. Offline firmware installation. It's not that common, but
> there still appear ppl who can't use Ethernet cable and don't have
> another Linux machine to extract firmware using it. For them our
> script would be useless.
> 
> So my another idea is to make our script accept passing path to the
> driver as a command line argument. So one can download
> broadcom-wl-6.30.163.46.tar.bz2, put it on a USB flash and call
> b43_install_firmware /mnt/usb/broadcom-wl-6.30.163.46.tar.bz2
> We should also remember to allows passing other archives as an
> argument (wl_apsta-3.130.20.0.o at least!).

How do you plan to implement this? Another list of checksums
for all kinds of tarballs, or some kind of heuristics?
Note that if this contains too many heuristics, distros might
dislike it, because this tends to generate funny bugs.

And on the online-functionality:
How do you detect which firmware to download? Note that I thought
about this in the early bcm43xx days, too. The driver had special
versioned MODULE_FIRMWARE markers (that we removed last year or so,
because they were horribly outdated), so that an automatic tool
could decide what firmware to download. Are you going to decide
by kernel version? What for patched/backported kernels? The plain
firmware file names from the remaining MODULE_FIRMWAREs probably
isn't enough information.

-- 
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20140801/92734a7f/attachment.sig>

b43-fwcutter: add helper script for getting firmware

[Rafał Miłecki]

On 1 August 2014 20:44, Michael B?sch <m@bues.ch> wrote:
>> 4) Scripts like install_bcm43xx_firmware in openSUSE
>> 5) Scripts like postinst in Debian
>> Way too many of them. Way too complex.
>>
>> My idea is to add a helper script to the b43-tools / fwcutter and put
>> it during install in $(PREFIX)/bin/. This way we will know that every
>> user who installed b43-fwcutter also owns our script. Then we just
>> tell our users "hey, fire your b43_install_firmware" (or whatever).
>>
>> Of course distros still we be able to make it automatic. For example
>> Debian's postinst could simply call this script and simplify its
>> postinst. Same for RPMs.
>
> Ok this sounds good. _But_ I am not a distribution guy.
> We should probably contact the Debian, Fedora, SuSE or whatever package
> maintainer to get comments on this.
> It would be bad, if we ship something, that turns out to be useless for
> distro packages, for whatever reason.

OK, I'll try to contact distribution guys, but I believe we have to
have some plan well-specified first.


>> Now, if you like my idea above, there is one more thing worth
>> considering. Offline firmware installation. It's not that common, but
>> there still appear ppl who can't use Ethernet cable and don't have
>> another Linux machine to extract firmware using it. For them our
>> script would be useless.
>>
>> So my another idea is to make our script accept passing path to the
>> driver as a command line argument. So one can download
>> broadcom-wl-6.30.163.46.tar.bz2, put it on a USB flash and call
>> b43_install_firmware /mnt/usb/broadcom-wl-6.30.163.46.tar.bz2
>> We should also remember to allows passing other archives as an
>> argument (wl_apsta-3.130.20.0.o at least!).
>
> How do you plan to implement this? Another list of checksums
> for all kinds of tarballs, or some kind of heuristics?
> Note that if this contains too many heuristics, distros might
> dislike it, because this tends to generate funny bugs.

No heuristics. Extracting any passed archive and looking for binary
objects in it would *surly* contain some bugs.

We update binaries (lwfinger.com/b43-firmware/) rarely, once a year
maybe? So having a simple checksum of .tar.bz2 should make the trick.
I need to know which archive I'm dealing with to know the location of
.o file only.


> And on the online-functionality:
> How do you detect which firmware to download? Note that I thought
> about this in the early bcm43xx days, too. The driver had special
> versioned MODULE_FIRMWARE markers (that we removed last year or so,
> because they were horribly outdated), so that an automatic tool
> could decide what firmware to download. Are you going to decide
> by kernel version? What for patched/backported kernels? The plain
> firmware file names from the remaining MODULE_FIRMWAREs probably
> isn't enough information.

Do you think about problem of using new version of script with old
kernel? Like using a fresh script wild old kernel that e.g. didn't
support firmware rev 598+?
What about handling it in a kernel? If we ever start supporting new,
backward incompatible, version of firmware, maybe we should use
something like a /lib/firmware/b43-v123/?
In such situation we could make script prepare both:
/lib/firmware/b43/
and
/lib/firmware/b43-v123/

Script wouldn't need to check for the current kernel then. And user
could switch between kernels without changing user space.

Does it make sense?

-- 
Rafa?

b43-fwcutter: add helper script for getting firmware

[Michael Büsch]

On Fri, 1 Aug 2014 23:26:55 +0200
Rafa? Mi?ecki <zajec5@gmail.com> wrote:

> No heuristics. Extracting any passed archive and looking for binary
> objects in it would *surly* contain some bugs.
> 
> We update binaries (lwfinger.com/b43-firmware/) rarely, once a year
> maybe? So having a simple checksum of .tar.bz2 should make the trick.
> I need to know which archive I'm dealing with to know the location of
> .o file only.

I completely agree here.

> > And on the online-functionality:
> > How do you detect which firmware to download? Note that I thought
> > about this in the early bcm43xx days, too. The driver had special
> > versioned MODULE_FIRMWARE markers (that we removed last year or so,
> > because they were horribly outdated), so that an automatic tool
> > could decide what firmware to download. Are you going to decide
> > by kernel version? What for patched/backported kernels? The plain
> > firmware file names from the remaining MODULE_FIRMWAREs probably
> > isn't enough information.
> 
> Do you think about problem of using new version of script with old
> kernel? Like using a fresh script wild old kernel that e.g. didn't
> support firmware rev 598+?

Yes.

> What about handling it in a kernel? If we ever start supporting new,
> backward incompatible, version of firmware, maybe we should use
> something like a /lib/firmware/b43-v123/?

Yes, we should _have_ done this. But we didn't.
We could simply ignore old incompatible kernels and in future do this:

> In such situation we could make script prepare both:
> /lib/firmware/b43/
> and
> /lib/firmware/b43-v123/
> 
> Script wouldn't need to check for the current kernel then. And user
> could switch between kernels without changing user space.
> 
> Does it make sense?

sure.
Do symbolic links to directories work for firmware fetching (Need to check 
both udev and in-kernel mechanisms)

-- 
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20140801/38c5c365/attachment.sig>

b43-fwcutter: add helper script for getting firmware

[Rafał Miłecki]

On 1 August 2014 23:35, Michael B?sch <m@bues.ch> wrote:
>> What about handling it in a kernel? If we ever start supporting new,
>> backward incompatible, version of firmware, maybe we should use
>> something like a /lib/firmware/b43-v123/?
>
> Yes, we should _have_ done this. But we didn't.
> We could simply ignore old incompatible kernels (...)

I think we broke that compatibility in 3.2, which is one before the
oldest supported longterm. I don't see a point in fixing that old
breakage now, when only 2.6.32 keeps affected. But I'll be more
careful in the future!

Thanks for discussion!

b43-fwcutter: add helper script for getting firmware

[Rafał Miłecki]

On 1 August 2014 at 19:41, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> Installing a firmware was always kind of challenge for end users.
> There were many tries of solving this:
> 1) Distribution wiki pages with descriptions
> 2) b43 wiki page trying to handle the most common distros
> 3) Extra non-free packages
> 4) Scripts like install_bcm43xx_firmware in openSUSE
> 5) Scripts like postinst in Debian
> Way too many of them. Way too complex.
>
> My idea is to add a helper script to the b43-tools / fwcutter and put
> it during install in $(PREFIX)/bin/. This way we will know that every
> user who installed b43-fwcutter also owns our script. Then we just
> tell our users "hey, fire your b43_install_firmware" (or whatever).
>
> Of course distros still we be able to make it automatic. For example
> Debian's postinst could simply call this script and simplify its
> postinst. Same for RPMs.
>
> [The second part]
>
> Now, if you like my idea above, there is one more thing worth
> considering. Offline firmware installation. It's not that common, but
> there still appear ppl who can't use Ethernet cable and don't have
> another Linux machine to extract firmware using it. For them our
> script would be useless.
>
> So my another idea is to make our script accept passing path to the
> driver as a command line argument. So one can download
> broadcom-wl-6.30.163.46.tar.bz2, put it on a USB flash and call
> b43_install_firmware /mnt/usb/broadcom-wl-6.30.163.46.tar.bz2
> We should also remember to allows passing other archives as an
> argument (wl_apsta-3.130.20.0.o at least!).
>
>
> Do you like this idea? Could someone handle this?

I'd like to resurrect this idea. So far I've prepared wiki page
describing the problem and our plan, see:
https://wireless.wiki.kernel.org/en/users/drivers/b43/firmware

Is there anything else you would like to add? Before I start
contacting distribution maintainers?

-- 
Rafa?

b43-fwcutter: add helper script for getting firmware

[Michael Büsch]

On Wed, 18 Feb 2015 11:03:03 +0100
Rafa? Mi?ecki <zajec5@gmail.com> wrote:

> On 1 August 2014 at 19:41, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
> > Installing a firmware was always kind of challenge for end users.
> > There were many tries of solving this:
> > 1) Distribution wiki pages with descriptions
> > 2) b43 wiki page trying to handle the most common distros
> > 3) Extra non-free packages
> > 4) Scripts like install_bcm43xx_firmware in openSUSE
> > 5) Scripts like postinst in Debian
> > Way too many of them. Way too complex.
> >
> > My idea is to add a helper script to the b43-tools / fwcutter and put
> > it during install in $(PREFIX)/bin/. This way we will know that every
> > user who installed b43-fwcutter also owns our script. Then we just
> > tell our users "hey, fire your b43_install_firmware" (or whatever).
> >
> > Of course distros still we be able to make it automatic. For example
> > Debian's postinst could simply call this script and simplify its
> > postinst. Same for RPMs.
> >
> > [The second part]
> >
> > Now, if you like my idea above, there is one more thing worth
> > considering. Offline firmware installation. It's not that common, but
> > there still appear ppl who can't use Ethernet cable and don't have
> > another Linux machine to extract firmware using it. For them our
> > script would be useless.
> >
> > So my another idea is to make our script accept passing path to the
> > driver as a command line argument. So one can download
> > broadcom-wl-6.30.163.46.tar.bz2, put it on a USB flash and call
> > b43_install_firmware /mnt/usb/broadcom-wl-6.30.163.46.tar.bz2
> > We should also remember to allows passing other archives as an
> > argument (wl_apsta-3.130.20.0.o at least!).
> >
> >
> > Do you like this idea? Could someone handle this?
> 
> I'd like to resurrect this idea. So far I've prepared wiki page
> describing the problem and our plan, see:
> https://wireless.wiki.kernel.org/en/users/drivers/b43/firmware
> 
> Is there anything else you would like to add? Before I start
> contacting distribution maintainers?

I am all for pulling distribution extensions into mainline.
I did so some time ago for some of the debian specific changes.

Generic scripts are good, if everybody can use them.

-- 
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20150218/79694e32/attachment.sig>

b43-fwcutter: add helper script for getting firmware

[Larry Finger]

On 02/18/2015 04:03 AM, Rafa? Mi?ecki wrote:
> On 1 August 2014 at 19:41, Rafa? Mi?ecki <zajec5@gmail.com> wrote:
>> Installing a firmware was always kind of challenge for end users.
>> There were many tries of solving this:
>> 1) Distribution wiki pages with descriptions
>> 2) b43 wiki page trying to handle the most common distros
>> 3) Extra non-free packages
>> 4) Scripts like install_bcm43xx_firmware in openSUSE
>> 5) Scripts like postinst in Debian
>> Way too many of them. Way too complex.
>>
>> My idea is to add a helper script to the b43-tools / fwcutter and put
>> it during install in $(PREFIX)/bin/. This way we will know that every
>> user who installed b43-fwcutter also owns our script. Then we just
>> tell our users "hey, fire your b43_install_firmware" (or whatever).
>>
>> Of course distros still we be able to make it automatic. For example
>> Debian's postinst could simply call this script and simplify its
>> postinst. Same for RPMs.
>>
>> [The second part]
>>
>> Now, if you like my idea above, there is one more thing worth
>> considering. Offline firmware installation. It's not that common, but
>> there still appear ppl who can't use Ethernet cable and don't have
>> another Linux machine to extract firmware using it. For them our
>> script would be useless.
>>
>> So my another idea is to make our script accept passing path to the
>> driver as a command line argument. So one can download
>> broadcom-wl-6.30.163.46.tar.bz2, put it on a USB flash and call
>> b43_install_firmware /mnt/usb/broadcom-wl-6.30.163.46.tar.bz2
>> We should also remember to allows passing other archives as an
>> argument (wl_apsta-3.130.20.0.o at least!).
>>
>>
>> Do you like this idea? Could someone handle this?
>
> I'd like to resurrect this idea. So far I've prepared wiki page
> describing the problem and our plan, see:
> https://wireless.wiki.kernel.org/en/users/drivers/b43/firmware
>
> Is there anything else you would like to add? Before I start
> contacting distribution maintainers?

That looks good. For what it is worth, the openSUSE script would be a good 
starting point for network installations. It only uses standard utilities, and 
the only assumption it makes is that b43-fwcutter is available.

The off-line firmware installation is more important. File 
http://www.lwfinger.com/b43-firmware/no_net_install_bcm43xx_firmware.tar.bz2 
handles the problem, but only for a single version of the firmware.

I think you are ready to contact the distros.

Larry