lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YPfRf8dgFd+u5hzm@equinox>
Date:   Wed, 21 Jul 2021 08:49:19 +0100
From:   Phillip Potter <phil@...lpotter.co.uk>
To:     Larry Finger <Larry.Finger@...inger.net>
Cc:     gregkh@...uxfoundation.org, dan.carpenter@...cle.com,
        linux-kernel@...r.kernel.org, linux-staging@...ts.linux.dev,
        fabioaiuto83@...il.com
Subject: Re: [PATCH resend] staging: rtl8188eu: move all source files from
 core subdirectory

On Tue, Jul 20, 2021 at 07:22:26PM -0500, Larry Finger wrote:
> On 7/20/21 4:00 AM, Fabio Aiuto wrote:
> > maybe the information we will need one day is:
> > 
> > will the core/-os_dep/-hal/-include/-directory-structure be
> > welcomed in mainline wireless subsystem, when an rtl* driver
> > will be perfectly tuned?
> > 
> > At the moment I can't see such a directory organization
> > in any of the realtek wireless driver.
> > 
> > Sure there's time for that;),
> 
> The question is how much lipstick do you want to put on that pig? The
> current version does not use cfg80211, and it does not work with
> NetworkManager or a modern hostapd to create an AP.
> 
> If you want to get the rtl8188eu driver in shape to be added to the regular
> drivers section, then I suggest you start with the v5.2.2.4 branch of
> https://github.com/lwfinger/rtl8188eu.git. Many users of the RTL8188EU chip
> use that driver. At least that version fixes the two problems listed above.
> If you want to flatten the directory structure, you can do it there and
> offline.
> 
> I want to caution you that following this path will take a lot of time, but
> once you get it into kernel shape, it will at least be useful. I have never
> had the time, nor the ambition to undertake this effort.
> 
> Larry
> 
Dear Larry,

Whilst I (and no doubt others) are happy to look into what you've
suggested, I do have a few questions:
(1) Why is the version from github not the one in staging?
(2) On a related note, working on it offline is difficult in terms of
proving contributions, particularly for a kernel mentee such as myself.

Might I suggest replacing this driver with the one you suggested
entirely, so work on it can continue in public? I am happy to submit
this and continue work if you think it would be viable. Many thanks and
I appreciate your thoughts on this.

Regards,
Phil

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ