Thank you very much for explaining, lxoliva. I have recently started to learn reverse engineering. Ideally, I want to write a replacement for iwlwifi, and I thought familiarising myself with rtlwifi might be a good start. Are there any drivers/firmware (or ideally userspace utilities) which need a libre replacement which could be a shorter, easier goal?
Perhaps there are some almost fully-liberated drivers/firmware that need one last component reverse-engineered? I feel I am definitely not ready to tackle a large blob yet. Thank you, ar. On Fri, 30 Oct 2020 at 2:23 am, Alexandre Oliva<[email protected]> wrote: On Oct 28, 2020, "[email protected]" <[email protected]> wrote: > I think this may be a false positive. It appears to be an array of > channel frequencies for 5GHz. You may confirm whether this is the case by running deblob-check --print-marked-false-positives You'll likely find channel5g recognized as a false positive, i.e., not as something that needs cleaning up. I suppose you may be assuming we found something problematic in rtlwifi/core.c and are looking for the reason. It's not any blob or apparent blob in there. It's just infrastructure that other blob-loading drivers rely on. See, the only thing we change in RTLWIFI is the request_firmware call in rtlwifi/core.c to reject_firmware. That's what the 'reject_firmware' command does. Several other drivers under rtlwifi rely on that request/reject_firmware to request non-Free firmware, and there aren't any uses thereof to load Free firmware. That's why we disable it. So, there's nothing wrong with code conditioned on RTLWIFI per se, it's just the uses thereof that are not FSDG-compliant, and require adjusting RTLWIFI to deal with the disabled blob loading. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer
_______________________________________________ linux-libre mailing list [email protected] http://www.fsfla.org/cgi-bin/mailman/listinfo/linux-libre
