rtlwifi false positive(?)

[a.reviewer1234 at yahoo.com]

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<lxoliva at fsfla.org> wrote:   On Oct 28, 2020, "a.reviewer1234 at yahoo.com" <a.reviewer1234 at yahoo.com> 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
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.fsfla.org/pipermail/linux-libre/attachments/20201030/e7a44914/attachment.html>