<div id="ymail_android_signature">Thank you very much for explaining, lxoliva.</div><div id="yMail_cursorElementTracker_1604068565983"><br></div><div id="yMail_cursorElementTracker_1604068754172"><br></div><div id="yMail_cursorElementTracker_1604068566130">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?</div><div id="yMail_cursorElementTracker_1604068745478"><br></div><div id="yMail_cursorElementTracker_1604068748500"><br></div><div id="yMail_cursorElementTracker_1604068745614">Perhaps there are some almost fully-liberated drivers/firmware that need one last component reverse-engineered?</div><div id="yMail_cursorElementTracker_1604068705020"><br></div><div id="yMail_cursorElementTracker_1604068750529"><br></div><div id="yMail_cursorElementTracker_1604068705143">I feel I am definitely not ready to tackle a large blob yet.</div><div id="yMail_cursorElementTracker_1604068756428"><br></div><div id="yMail_cursorElementTracker_1604068756564"><br></div><div id="yMail_cursorElementTracker_1604068560482">Thank you, ar.</div> <br> <blockquote style="margin: 0 0 20px 0;"> <div style="font-family:Roboto, sans-serif; color:#6D00F6;"> <div>On Fri, 30 Oct 2020 at 2:23 am, Alexandre Oliva</div><div><lxoliva@fsfla.org> wrote:</div> </div> <div style="padding: 10px 0 0 20px; margin: 10px 0 0 0; border-left: 1px solid #6D00F6;"> On Oct 28, 2020, "<a shape="rect" ymailto="mailto:a.reviewer1234@yahoo.com" href="mailto:a.reviewer1234@yahoo.com">a.reviewer1234@yahoo.com</a>" <<a shape="rect" ymailto="mailto:a.reviewer1234@yahoo.com" href="mailto:a.reviewer1234@yahoo.com">a.reviewer1234@yahoo.com</a>> wrote:<div class="yqt6856233737" id="yqtfd48927"><br clear="none"><br clear="none">> I think this may be a false positive. It appears to be an array of<br clear="none">> channel frequencies for 5GHz.</div><br clear="none"><br clear="none">You may confirm whether this is the case by running<br clear="none">deblob-check --print-marked-false-positives<br clear="none"><br clear="none">You'll likely find channel5g recognized as a false positive, i.e., not<br clear="none">as something that needs cleaning up.<br clear="none"><br clear="none">I suppose you may be assuming we found something problematic in<br clear="none">rtlwifi/core.c and are looking for the reason.<br clear="none"><br clear="none">It's not any blob or apparent blob in there.  It's just infrastructure<br clear="none">that other blob-loading drivers rely on.<br clear="none"><br clear="none">See, the only thing we change in RTLWIFI is the request_firmware call in<br clear="none">rtlwifi/core.c to reject_firmware.  That's what the 'reject_firmware'<br clear="none">command does.<br clear="none"><br clear="none">Several other drivers under rtlwifi rely on that request/reject_firmware<br clear="none">to request non-Free firmware, and there aren't any uses thereof to load<br clear="none">Free firmware.  That's why we disable it.<br clear="none"><br clear="none">So, there's nothing wrong with code conditioned on RTLWIFI per se, it's<br clear="none">just the uses thereof that are not FSDG-compliant, and require adjusting<br clear="none">RTLWIFI to deal with the disabled blob loading.<br clear="none"><br clear="none">-- <br clear="none">Alexandre Oliva, happy hacker<br clear="none"><a shape="rect" href="https://FSFLA.org/blogs/lxo/" target="_blank">https://FSFLA.org/blogs/lxo/</a><br clear="none">Free Software Activist<br clear="none">GNU Toolchain Engineer<div class="yqt6856233737" id="yqtfd33253"><br clear="none"></div> </div> </blockquote>