Hi intrigeri Thanks for following up on this discussion. intrigeri <intrigeri@debian.org> writes: > Hi Gaudenz, > > meta: > > * I'm replying on #749109, as this part of the discussion is about > code that's being added to live-config, not to broadcom-sta. > * Daniel: sorry for the useless ping sent earlier this month on > #748679, I was confused by the remaining tags left there > after cloning. > * I've tried to clarify the status of these two bug reports in the > BTS, and the relationship between them, which seemed very confusing > to me initially; sorry if I messed something up. I agree. I'm still not very convinced that the separation into a script in live-config and a pci-id list in broadcom-sta makes much sense. But I don't care enough to further argue about that. > > Gaudenz Steinlin wrote (12 Jun 2014 19:07:10 GMT) : >> - In some parts it looks like it should be a general wlan driver >> selection mechanism. Which would be great, but then overrides are >> stored in /usr/share/live/config/broadcom-sta/ and the script is >> called 1190-broadcom-sta. > > I've seen broadcom-sta support requested quite often on the Tails user > support channels, while I don't remember anything similar for other > drivers, so I say let's get the ad-hoc support for broadcom-sta in > first, hopefully in time for Jessie, and then we'll see if/how it can > be generalized. Fair enough? I don't think a generalized script is necessary atm. It may become necessary if more proprietary wlan drivers become relevant. But it really hope this won't happen. > >> - It uses 14e44 as a first filter in the script. While it's true that >> the ID of all currently supported devices starts with this string, the >> broadcom vendor ID is only 14e4. The last 4 is part of the device ID. >> - The blacklisting logic is the wrong way around. If broadcom-sta is >> selected as a driver, all entries in >> /etc/modprobe.d/broadcom-sta-dkms.conf should be blacklisted. If it's >> not selected, they should NOT be blacklisted. Additionally the wl >> kernel module should be blacklisted in this case. >> - checking for a state file makes this script basically useless with >> persistency on removable media. When moving to live media (ie USB >> stick) from one system to another you want to rerun this script each >> time. State files are nice for user preferences, but I don't see a use >> case for them for hardware configuration. > > Care to provide a patch that fixes these problems? The original script I provided in #748679 does not have any of these problems. I suggest to just take this script. To make it super easy to apply it, I've attached the script again to this mail. If there is a realistic chance, that a script that will be useful for live distributions that want to support booting on systems needing wl.ko and systems not needing it will make it's way into live-config, I'm also ready to further work on this script if it has any problems I'm not aware of. Gaudenz
Attachment:
1160-broadcom-sta
Description: Binary data