rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

[Brian Witte]

Hauke, Johannes, or any other backports users/developers,

I recently spoke to Luis Chamberlain about a few different things 
related my new shared maintainership of rtw,rtl drivers on GitHub that 
are under Larry Finger's account:

https://github.com/lwfinger?tab=repositories

The main thing I wanted to discuss is related to the sustainability, 
longevity, and utility of maintaining a few in-tree, standalone manual 
(#if #else #endif) backports for realtek:

https://github.com/lwfinger/rtw88
https://github.com/lwfinger/rtw89

If you want to see where Larry introduces me, it's here:
https://github.com/lwfinger/rtw88/issues/151#issuecomment-1604503581

I just wanted to reach out about these repos and the options and 
tradeoffs with porting them over to the backports.git project in a way 
that will benefit the larger community and our existing users.

I am able to begin the work on these drivers if we decide to try and 
merge them into backports.git, but I need to understand a few things 
since my understanding is often the biggest limitation in all of this.

On more than one occasion, I have gotten confused about how Linux 
backports does things so I want to make sure I am making the right 
assumptions about how it works with respect to commit history and a few 
other things for their respective drivers.

My current understanding re: commit history is as follows:

The main Linux backports project does not preserve the commit history of 
individual drivers as they exist in their original trees that they are 
taken from. The main goal of the backports project is taking code from 
newer Linux kernel versions and adapting them so they can be compiled 
and run on older kernel versions. This backporting process is automated 
by applying a series of patches to make the newer code compatible with 
the older kernel via automation defined in the backports.git repo 
through Makefile, Kconfig, dependent .c or .h files, etc. and of course 
the "semantic patch language" scripts of coccinelle.

Because the goal is to make new code work with old kernels, rather than 
to maintain a faithful, version-controlled history of that code, the 
commit history for individual drivers is not included in project's 
focus. The version control history in the backports.git repository 
serves to track changes to the backporting process itself, rather than 
to preserve the history of the backported code (I know that may be 
obvious, but I need to make sure I am not mistaken.)

In a nutshell, the Linux backports project is geared towards 
compatibility and functionality, not towards historical preservation of 
codebase evolution.

The second thing I want to make sure I understand is how users can get 
backports for a driver via the Linux backports project:

A happy path would look like them pulling down a tar of backports for 
their kernel version from 
https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/ and 
then running something like:

```sh
# as a user
make defconfig-rtlwifi
make -j4
# as root
make install
# reboot and enjoy
```

If a feature they need is not in a stable version, they will then have 
to execute a small series of extra steps to compile their own backports 
release and then use that; whether it's against linux-next or some other 
tree. This is a documented and relatively well-traveled path in kernel 
developer terms, but is likely out of reach for many "regular" users. I 
think it is fair to say that this would require them to be a closer to a 
"developer" or experienced Linux user or administrator. They also may 
not know about or be able to find the docs for doing so. A GitHub repo 
with their device driver name is often what they find first.

The last thing I want to make sure I have straight is the value of 
backports.git for wireless drivers generally because there seem to be many:

For maintainers/developers, backports.git offers a standardized, 
automated system that minimizes errors, streamlines many aspects of 
building, testing, and iterating, and allows for community-vetted (more 
eyes), secure code. This centralization frees maintainers to focus on 
other development priorities like fixing/reproducing bugs and landing 
patches upstream.

For users, backports.git provides a stable way to access these new 
features and fixes. It also can be quite simple if you have the right 
kernel version, it lines up with the feature you need, or you have the 
requisite experience and can find then dive into more "developer-like" 
documentation.

For the community, integrating the drivers into backports.git holds 
benefits for downstream projects like OpenWrt, which already rely on 
backports as a core design feature. Therefore OpenWrt and similar 
projects can more seamlessly and securely include them in their 
distributions, enhancing both device support and the end-user 
experience. In addition, the upstream drivers benefit due to increased 
visibility and accessibility, encouraging wider community engagement for 
testing, bug reporting, and code contributions.

This approach serves to unify efforts, improve security, and facilitate 
a solid, shared pipeline for maintainers, users, and the larger community.

In conclusion, there are a few questions I am trying to answer for 
myself, but could use any feedback on.

1. How critical is the preservation of commit history for effective 
debugging and bisecting when issues arise in the backported drivers? We 
have the commit history in our GitHub repos, but they would not be 
present in drivers compiled from backports.git. Is there a way to have 
"the best of both worlds" or mitigate the effects of lacking that history?

2. Are there methods to automate or simplify the process for users who 
need features not yet available in stable releases, to reduce the skill 
barrier?

3. How can I help the backports project directly (rtw related or not)?

4. How can we best leverage the years of effort and modifications (#if 
#else #endif macros) made by Larry in these stand-alone repositories to 
inform the technical work of porting them to the shared backports framework?

5. Given the popularity and visibility of the rtw88 and rtw89 GitHub 
repositories, as indicated by their star counts, issue activity, and 
search engine ranking, what strategies can we employ to maintain this 
level of user engagement and support if we transition to backports.git? 
Would mirroring the code and providing custom-tailored instructions in 
the READMEs serve dual purposes of user support and elevating the 
visibility of backports.git in the larger community? Is this a welcomed 
proposition?

I understand that many of these questions ultimately require hands-on 
work and investigation on my part. However, I believe now is an 
opportune time to engage the community in these discussions.

I will be attending the Linux Plumbers Conference next month on behalf 
of Larry and myself and would like to use this as a start to further 
explore potential collaborations and conversations around these topics.

Lastly, I want to thank the backports.git maintainers for providing an 
invaluable tool for the Linux community. Also, thank you Luis for 
getting me started on having these conversations.

Thank you for your time, and I look forward to future discussions.

Thanks,
Brian Witte
--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

[Johannes Berg]

Hi,

> I just wanted to reach out about these repos and the options and 
> tradeoffs with porting them over to the backports.git project in a way 
> that will benefit the larger community and our existing users.

Can you explain what you're trying to achieve by that?

And even, what is the reason to have these out-of-tree versions of the
drivers?

The backports project doesn't in itself work with out-of-tree drivers.
It _creates_ out-of-tree drivers, yes, but it takes the source of these
always from the latest upstream kernel.

So since I'm not sure what the github trees are even used for, let's say

 1) these are used to provide additional fixes or hardware support over
    what the upstream kernel already has

   -> this is something backports will not support, the source driver
      must be fully upstream

      (OK, strictly speaking, that's not true - you could patch the
       upstream driver before generating backports, but that seems
       painful)

 2) these are just used to provide newer drivers to users of
    older kernels

   -> this is exactly what backports pretty much already does


> I am able to begin the work on these drivers if we decide to try and 
> merge them into backports.git,
> 

They probably already ship in the current backports, since we generally
include all wifi drivers. However, it hasn't gotten a lot of attention
in the past few years other than our (Intel's) internal maintenance for
iwlwifi.

> but I need to understand a few things 
> since my understanding is often the biggest limitation in all of this.

Sure :)

> On more than one occasion, I have gotten confused about how Linux 
> backports does things so I want to make sure I am making the right 
> assumptions about how it works with respect to commit history and a few 
> other things for their respective drivers.
> 
> My current understanding re: commit history is as follows:
> 
> The main Linux backports project does not preserve the commit history of 
> individual drivers as they exist in their original trees that they are 
> taken from.

Correct.

> The main goal of the backports project is taking code from 
> newer Linux kernel versions and adapting them so they can be compiled 
> and run on older kernel versions. 

Yes.

> This backporting process is automated 
> by applying a series of patches to make the newer code compatible with 
> the older kernel via automation defined in the backports.git repo 
> through Makefile, Kconfig, dependent .c or .h files, etc. and of course 
> the "semantic patch language" scripts of coccinelle.

Yes.

> Because the goal is to make new code work with old kernels, rather than 
> to maintain a faithful, version-controlled history of that code, the 
> commit history for individual drivers is not included in project's 
> focus. The version control history in the backports.git repository 
> serves to track changes to the backporting process itself, rather than 
> to preserve the history of the backported code (I know that may be 
> obvious, but I need to make sure I am not mistaken.)

Yes.

There _is_ a script (devel/git-tracker.py) that can "port" over history
from an upstream tree to a backport-generated git tree, but I'm not sure
I'd generally recommend using it. It's geared fairly specifically to our
internal development process which is actually that people work in such
a backport tree (we even publish a version of it [1]).


[1]
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/

> In a nutshell, the Linux backports project is geared towards 
> compatibility and functionality, not towards historical preservation of 
> codebase evolution.

It's just not relevant - the historical preservation of the code base
happens in the upstream Linux kernel project.


> The second thing I want to make sure I understand is how users can get 
> backports for a driver via the Linux backports project:
> 
> A happy path would look like them pulling down a tar of backports for 
> their kernel version from 
> https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/ and 
> then running something like:
> 
> ```sh
> # as a user
> make defconfig-rtlwifi
> make -j4
> # as root
> make install
> # reboot and enjoy
> ```

Yes, pretty much. It'd require someone actually maintaining backports
more reliably and creating packages though :)

> If a feature they need is not in a stable version, they will then have 
> to execute a small series of extra steps to compile their own backports 
> release and then use that; whether it's against linux-next or some other 
> tree. This is a documented and relatively well-traveled path in kernel 
> developer terms, but is likely out of reach for many "regular" users. 

Well you could do that, but the backports maintainer could, in theory,
also offer a snapshot version.

This stuff is also fairly well scripted, I don't think it's _that_ much
more effort than "make ..." stuff above? Though it does require more
tooling (like spatch) to be installed.

> I 
> think it is fair to say that this would require them to be a closer to a 
> "developer" or experienced Linux user or administrator. They also may 
> not know about or be able to find the docs for doing so. A GitHub repo 
> with their device driver name is often what they find first.

If it exists ;-)


I mean, if you wanted that, you _could_ generate such a repo with
different tags/branches/etc. even with individual upstream commits using
the git-tracker tool. But it can take a long time to run and it's often
difficult to get the backports to even work for all individual commits,
so you'd probably care more about specific snapshots like RCs etc.

> The last thing I want to make sure I have straight is the value of 
> backports.git for wireless drivers generally because there seem to be many:
> 
> For maintainers/developers, backports.git offers a standardized, 
> automated system that minimizes errors, streamlines many aspects of 
> building, testing, and iterating, and allows for community-vetted (more 
> eyes), secure code. This centralization frees maintainers to focus on 
> other development priorities like fixing/reproducing bugs and landing 
> patches upstream.

Well, I think that's overselling it a bit, given that it's been
languishing. We could also probably contribute more fixes than we
currently did, purely based on our internal version.

But yeah, it was _meant_ to basically make it easier to do backports, by
having everyone pitch in together ... did that happen? Not that much.


> For users, backports.git provides a stable way to access these new 
> features and fixes. It also can be quite simple if you have the right 
> kernel version, it lines up with the feature you need, or you have the 
> requisite experience and can find then dive into more "developer-like" 
> documentation.

I'm not sure it's really easy to use right now because there's no
regular maintenance.

> For the community, integrating the drivers into backports.git
> 

I'm not sure I'd argue there's even a notion of "integrating the drivers
into backports.git". After all, backports.git doesn't contain drivers.
Though yeah, arguably having a driver actually work with backports takes
some work on the backports side, something you could call "integration".

> holds 
> benefits for downstream projects like OpenWrt, which already rely on 
> backports as a core design feature. Therefore OpenWrt and similar 
> projects can more seamlessly and securely include them in their 
> distributions, enhancing both device support and the end-user 
> experience. In addition, the upstream drivers benefit due to increased 
> visibility and accessibility, encouraging wider community engagement for 
> testing, bug reporting, and code contributions.

:)

> This approach serves to unify efforts, improve security, and facilitate 
> a solid, shared pipeline for maintainers, users, and the larger community.
> 
> In conclusion, there are a few questions I am trying to answer for 
> myself, but could use any feedback on.
> 
> 1. How critical is the preservation of commit history for effective 
> debugging and bisecting when issues arise in the backported drivers? We 
> have the commit history in our GitHub repos, but they would not be 
> present in drivers compiled from backports.git. Is there a way to have 
> "the best of both worlds" or mitigate the effects of lacking that history?

Like I said above, you _could_ use git-tracker and create a new backport
for every (relevant) upstream commit, but then you end up fixing a lot
of intermittent backport issues:
Say some commit is introduced upstream that makes a patch in backports
no longer apply, but then let's say that commit is reverted pretty soon.
If you just follow the RCs, you might never notice. If you follow
individual commits, you'd have to adjust backports *twice* over it.

> 2. Are there methods to automate or simplify the process for users who 
> need features not yet available in stable releases, to reduce the skill 
> barrier?

It's not _that_ hard, basically just running "./gentree.py ..."?

Not sure what we could simplify there.


> 3. How can I help the backports project directly (rtw related or not)?

Depends how much work you want to put in? I think what'd help most right
now would be to actually have someone to do what Hauke used to do, which
was integrating patches from the list (and we'd probably have more of
them), and creating releases.

> 4. How can we best leverage the years of effort and modifications (#if 
> #else #endif macros) made by Larry in these stand-alone repositories to 
> inform the technical work of porting them to the shared backports framework?

That's tricky, I don't think there's a good way to leverage that
directly. Also, backports tries to _minimize_ the ifdefs needed in
favour of providing spatches and API changes.

Also, looking at the rtw89 repo, I notice that it _only_ contains the
driver and attempts to make it compatible with all mac80211 versions,
which we had previously though of as basically a losing proposition, and
so backports ships the _entire_ wireless stack so that the coupling
between cfg80211/mac80211/driver is maintained.

As a result, I think the only way to use this would be for inspiration
when looking at something that backports didn't (yet) handle (well).

> 5. Given the popularity and visibility of the rtw88 and rtw89 GitHub 
> repositories, as indicated by their star counts, issue activity, and 
> search engine ranking, what strategies can we employ to maintain this 
> level of user engagement and support if we transition to backports.git? 
> Would mirroring the code and providing custom-tailored instructions in 
> the READMEs serve dual purposes of user support and elevating the 
> visibility of backports.git in the larger community? Is this a welcomed 
> proposition?

Given that nobody really seems to have much time to spend on the
backports project ... I think that'd be up to you.

You could generate backports for all Linux RCs and commit them to those
repos for example, in ascending order? You could even try to use the
git-tracker.py to generate individual commits, but as I described that
has some caveats. Or even provide linux-next snapshots in a separate
branch?

As long as you don't think of "backport outputs a tarball", I think you
can see a lot of choices, although not all of them will preserve a
patch-by-patch history of the driver.

> I understand that many of these questions ultimately require hands-on 
> work and investigation on my part. However, I believe now is an 
> opportune time to engage the community in these discussions.
> 
> I will be attending the Linux Plumbers Conference next month on behalf 
> of Larry and myself and would like to use this as a start to further 
> explore potential collaborations and conversations around these topics.

Maybe Luis will be there? I won't.

> Lastly, I want to thank the backports.git maintainers for providing an 
> invaluable tool for the Linux community. Also, thank you Luis for 
> getting me started on having these conversations.

:)

johannes
--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

[Brian Witte]

Johannes,

Thank you for the quick response.

 > Can you explain what you're trying to achieve by that?
 > what is the reason to have these out-of-tree versions of the
 > drivers?

Right, yes. I should clarify that better.

I will use this lwfinger/rtw89 repo as the example throughout this:
https://github.com/lwfinger/rtw89

First, as this caused confusion when Luis first began trying to
assist me:

lwfinger/rtw89 is an out-of-tree backport of the in-tree rtw89. outside
of documentation, files needed to build/manage the driver, and inserted
#if #else #endif statements for compatibility. It attempts to be a
"copy" of the upstream rtw89. there is no new hardware support or
capabilities built into it as far as I understand.

The purpose of this repo shares the same stated goal of Linux Backports
which is "taking code from newer Linux kernel versions and adapting
them so they can be compiled and run on older kernel versions."

Right now, the main way Larry does this is by filtering new rtw89
patches out of `wireless-next` and then incrementally applying them
via a git workflow using quilt and wiggle while applying #if #else
#endif for the changes between versions.

What I am trying to achieve:
1. Compatibility that reaches back further. Right now lwfinger/rtw89
repo only extends back to kernel version 5.7.
2. Ensure that users who visit the lwfinger/rtw89 GitHub page can
get their driver working if they are having issues.
3. Ease the burden of maintaining a backport manually.


 > The backports project doesn't in itself work with out-of-tree
 > drivers.
 > It _creates_ out-of-tree drivers, yes, but it takes the
 > source of these
 > always from the latest upstream kernel.

Right. yes. I understand.

 >   2) these are just used to provide newer drivers to users of
 >      older kernels

Yes, this is the main goal.

Ok, I need test this properly with rtw89 and a few different older
kernels. There were a few things that were unclear to me about how
backports works that are now more clear.

When I check for the rtw89 cards, I see:

     $ pwd
     /home/user/backports/backport/defconfigs

     $ cat check_for_rtw89_cards.awk
     BEGIN { found = 0 } # print line
     if found /8852AE|8851BE|8852BE|8852CE/ {
         print $0 found = 1 exit
     } END { if (found == 0) { print "not found" } }

     $ awk -f check_for_rtw89_cards.awk rtlwifi
     not found

I will start looking into getting rtw89 running in backports.git if
my tests show they are not yet supported.

Otherwise, alot of my understanding of how backports work was not
completely wrong and you made some important clarifications re:
usage and options that are available re: commit history.

So as far as how I can decide what I will do with the lwfinger/rtw89
repo and others like it entails figuring out the current state of
these drivers within the Linux backports project and how that can
fit in with our current users and how we support them.

Initially, I was just committed to putting in the work on these drivers
in their standalone GitHub repos, but it seems like consolidating
those efforts seems like the best approach if I can make it work. At
the end of the day, the lwfinger/rtw89 repo helps alot of people run
Linux that otherwise would not be able to so that is a big factor. But
now that you have clarified and reinforced a few key points, I am
more optimistic that I can figure something out.

 > Yes, pretty much. It'd require someone actually maintaining backports
 > more reliably and creating packages though :)

 > Depends how much work you want to put in? I think what'd help most
 > now would be to actually have someone to do what Hauke used to do,
 > which
 > was integrating patches from the list (and we'd probably have more of
 > them), and creating releases.

Ok, I am going to start actually running backports against different
setups to see what I can get a handle on and then follow-up
accordingly.

If there is anything specific to look into, let me know.

 > That's tricky, I don't think there's a good way to leverage that
 >directly. Also, backports tries to _minimize_ the ifdefs needed in
 >favour of providing spatches and API changes.
 >
 > Also, looking at the rtw89 repo, I notice that it _only_ contains the
 > driver and attempts to make it compatible with all mac80211 versions,
 > which we had previously though of as basically a losing proposition,

Ok, noted.

 > As long as you don't think of "backport outputs a tarball", I think
 > you
 > can see a lot of choices, although not all of them will preserve a
 > patch-by-patch history of the driver.

Right, yes.

Overall, there are few things to think about and there are a few
paths forward. The GitHub repos above and backports.git serve the
same purpose from a technical perspective, but differ with respect
to their distribution, installation, and capabilities (backports.git
more compatibility re: older kernel versions).

With that said, backports.git obviously can't fit any sort of
prescriptive support or installation model that I concoct to fit in
with how those GitHub repos and their users do things, but beginning
to figure out how those repos can be "downstream" of backports.git
and how that might work is a good thing to explore.

 > Given that nobody really seems to have much time to spend on the
 > backports project ... I think that'd be up to you.

Ok, understood.

Thank you,
Brian Witte

--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

[Johannes Berg]

Hi Brian,

> lwfinger/rtw89 is an out-of-tree backport of the in-tree rtw89. outside
> of documentation, files needed to build/manage the driver, and inserted
> #if #else #endif statements for compatibility. It attempts to be a
> "copy" of the upstream rtw89. there is no new hardware support or
> capabilities built into it as far as I understand.
> 
> The purpose of this repo shares the same stated goal of Linux Backports
> which is "taking code from newer Linux kernel versions and adapting
> them so they can be compiled and run on older kernel versions."

Right, OK.

> Right now, the main way Larry does this is by filtering new rtw89
> patches out of `wireless-next` and then incrementally applying them
> via a git workflow using quilt and wiggle while applying #if #else
> #endif for the changes between versions.

OK.

> What I am trying to achieve:
> 1. Compatibility that reaches back further. Right now lwfinger/rtw89
> repo only extends back to kernel version 5.7.

We did keep pushing the cut-off for backports, but I think it's at
4.something now? Also, some drivers have a higher cut-off, per the
'dependencies' file. The only RTL thing I see mentioned though is
RTL8723BS with 5.4.

> Ok, I need test this properly with rtw89 and a few different older
> kernels. There were a few things that were unclear to me about how
> backports works that are now more clear.
> 
> When I check for the rtw89 cards, I see:
> 
>      $ pwd
>      /home/user/backports/backport/defconfigs
> 
>      $ cat check_for_rtw89_cards.awk
>      BEGIN { found = 0 } # print line
>      if found /8852AE|8851BE|8852BE|8852CE/ {
>          print $0 found = 1 exit
>      } END { if (found == 0) { print "not found" } }
> 
>      $ awk -f check_for_rtw89_cards.awk rtlwifi
>      not found

Well not having anything in the defconfig doesn't mean much - we used to
at least try to build _all_ drivers that were possible (i.e. where
dependencies could be satisfied), and "allmodconfig" works here I think.

The copy-list takes all of the drivers under drivers/net/wireless/ (and
even some from staging), so it should be included.

> I will start looking into getting rtw89 running in backports.git if
> my tests show they are not yet supported.

Sure, please do try.

Also if you run into any missing backports let us know - there currently
aren't any not applied yet [1] and there are almost certainly some
integrated into iwlwifi [2] not sent as backports.git patches yet.

[1] https://patchwork.kernel.org/project/backports/list/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/backport-iwlwifi.git/


> Otherwise, alot of my understanding of how backports work was not
> completely wrong and you made some important clarifications re:
> usage and options that are available re: commit history.
> 
> So as far as how I can decide what I will do with the lwfinger/rtw89
> repo and others like it entails figuring out the current state of
> these drivers within the Linux backports project and how that can
> fit in with our current users and how we support them.

Makes sense.

> Initially, I was just committed to putting in the work on these drivers
> in their standalone GitHub repos, but it seems like consolidating
> those efforts seems like the best approach if I can make it work. 

Yeah, there's probably no good reason to have a repo per driver, doing
effectively the same thing more than once.

> Ok, I am going to start actually running backports against different
> setups to see what I can get a handle on and then follow-up
> accordingly.

Sure.

> If there is anything specific to look into, let me know.

Don't think so.

To get a better feel for how backports works and what all the
transformations look like etc., you can run gentree with --git-debug
command line, then it creates a git tree in the output and tracks there
individual *changes* it makes, for debug. Not to be confused with
tracking the input commits, of course, that's git-tracker's job.

If you do decide to use git-tracker, let me know, I'll check if we have
some additional changes internally to how it handles merges etc. We
might.

Have fun exploring! :-)
And do let us know if you hit any snags.

johannes
--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

[Larry Finger]

On 10/20/23 02:34, Johannes Berg wrote:
> Can you explain what you're trying to achieve by that? And even, what is the 
> reason to have these out-of-tree versions of the drivers?

Johannes,

I will give you a slightly different explanation than given by Brian.

When HP or Lenovo issue a new laptop model, they always use the latest Realtek 
wifi device - the rtw89 wifi 6 models at the moment. The new computers are 
released with Windows, which does have a driver for these devices.

If the user wants to run Linux, it is likely to be an older Ubuntu version 
running a kernel issued before rtw89 became part of the kernel. As a result, the 
user has no wifi under Linux. As far as I can tell, the equivalent problem does 
not happen for Intel or Athlon wifi hardware.

I created the rtw89 GitHub repo, and rtw88 (wifi 5) repo before that to backport 
the wireless-next version of the drivers into something that will build and run 
on kernels 5.4 or newer. With a 'git clone' and 'make', a novice user can get 
working wifi.

Keep in mind that most of our users are not very sophisticated. They frequently 
do not install the kernel headers even though the README tells them explicitly 
what the error means, and what they need to do for several of the popular 
distros. In addition, they struggle with the concept that out-of-kernel drivers 
must be built for the running kernel. Most can handle 'git pull', 'make', and 
sudo make (sign) install', but not anything more complicated.

As Brian said, I have done the maintenance by copying the patches from 
wireless-next into the GitHub repo, and handling the API changes in a manual 
fashion with '#ifdef LINUX_VERSION_CODE  ...' blocks. This works for me, but 
unlike me, Brian is a programmer, and he wants to create a script whenever he 
sees anything repetitive.

As it is unlikely that I will be doing this much longer, I support whatever he 
needs to make him comfortable. Although the kernels found in newer releases of 
various distros will eventually support the drivers, Realtek is adding wifi 7 
features to the drivers. Once they release the new hardware, it will be a short 
time until it is part of new models of laptops.

I do not see where backports has any part of the solution to this problem. As I 
had difficulty in getting it configured the first time I used that project, I do 
not see that as part of the solution for rtw88/89, other than it could be used 
to suggest solutions for the API changes. My experience allows me to look at the 
wireless-next and mainline kernels and determine what changes are needed. I am 
not sure I could explain that well enough to teach Brian.

Finally, I applaud Brian's initiative toward this project and I am content in 
knowing that the code is in good hands.

Larry

--
To unsubscribe from this list: send the line "unsubscribe backports" in

Re: rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

[Johannes Berg]

Hi Larry,

Sorry for the delay.

> I created the rtw89 GitHub repo, and rtw88 (wifi 5) repo before that to backport 
> the wireless-next version of the drivers into something that will build and run 
> on kernels 5.4 or newer. With a 'git clone' and 'make', a novice user can get 
> working wifi.

Right. That's pretty much the same as Brian was saying :)

> Keep in mind that most of our users are not very sophisticated. They frequently 
> do not install the kernel headers even though the README tells them explicitly 
> what the error means, and what they need to do for several of the popular 
> distros. In addition, they struggle with the concept that out-of-kernel drivers 
> must be built for the running kernel. Most can handle 'git pull', 'make', and 
> sudo make (sign) install', but not anything more complicated.

:)

> As Brian said, I have done the maintenance by copying the patches from 
> wireless-next into the GitHub repo, and handling the API changes in a manual 
> fashion with '#ifdef LINUX_VERSION_CODE  ...' blocks. This works for me, but 
> unlike me, Brian is a programmer, and he wants to create a script whenever he 
> sees anything repetitive.

Which is basically what backports already did.

> As it is unlikely that I will be doing this much longer, 

And you've been doing it for basically forever, and probably get thanked
for it much less than you should, so: big thank you from me for making
all this more accessible to "regular" users, and for helping out with
wireless in what's probably about two decades now. Much appreciated!

> I support whatever he 
> needs to make him comfortable. Although the kernels found in newer releases of 
> various distros will eventually support the drivers, Realtek is adding wifi 7 
> features to the drivers. Once they release the new hardware, it will be a short 
> time until it is part of new models of laptops.

Right.

> I do not see where backports has any part of the solution to this problem. 

Why not? It solves the exact same problem, no?

> As I 
> had difficulty in getting it configured the first time I used that project, I do 
> not see that as part of the solution for rtw88/89, other than it could be used 
> to suggest solutions for the API changes. 

Well that's looking at it from the view of the user of backports, but I
think Brian is suggesting that he could be the user of backports, and
then the "regular end user" is just consuming the _output_ of backports
that Brian has vetted, so it ends up being similarly "make && sudo make
install" (or so.)

> My experience allows me to look at the 
> wireless-next and mainline kernels and determine what changes are needed. I am 
> not sure I could explain that well enough to teach Brian.

Right. Keep in mind also though that you're doing it differently from
what backports does - backports comes with cfg80211 and mac80211, so
it's easier to do than adjusting to older versions of mac80211.

> Finally, I applaud Brian's initiative toward this project and I am content in 
> knowing that the code is in good hands.

:)

johannes

Re: rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

[Brian Witte]

Johannes,
> Right. Keep in mind also though that you're doing it differently from
> what backports does - backports comes with cfg80211 and mac80211, so
> it's easier to do than adjusting to older versions of mac80211.
I spoke to Larry off list and considering the cfg80211 and mac80211 
situation with older kernels further, he wants me to try and get a 
simple backports setup validated so that people can still
`make` and `make install`. He is focused on a few other important tasks 
and will probably get back with us here later, I just wanted to start 
running downhill with this ASAP so I slid in here.

I am going to first try a variation of the approach you suggested where 
I generate backports for Linux versions in the repo in ascending order 
then have our Makefile detect user's version and install accordingly.

Again, my understanding is often the bottleneck so I want to first say 
what I intend to do and then ask a question:

1. I want to use wireless-next as the upstream kernel source for 
building the backports, I would need to build all backports via the 
"package release" workflow [1] in order to provide users with a package 
that they can use without needing the upstream source on their machine, 
effectively giving them "a patch file" for compatibility for driver 
specific modifications and the up-to-date 80211 stack. I would then only 
need to decide which git tags for older kernels to use for the versions 
we want to support, create the packages, then include those in the 
repository.

[1] https://backports.wiki.kernel.org/index.php/Documentation/packaging

2. I am trying to figure this out currently, but am not entirely sure 
how granular the built package versions have to be in order to work with 
a users kernel version. How do I decide the coverage of an individual 
package per major-minor version or other variations? You mentioned RCs 
earlier. For this first PoC, I want to make sure users can get the 
driver working for any version they are running going back to 5.4.

After that, our Makefile and/or scripts it coordinates will have to 
detect the user version, then cd into that package, and install it 
properly. I am suspending any upstream commit history shenanigans for a 
later point as making sure the driver is performant and in-line with the 
up-to-date wireless stack. Being able to use those features and have a 
consistent API across the components is much more of a priority, at the 
moment.

Thank you for you help and patience with all of this. You have helped 
make this process an enjoyable thing to dive into and I am excited to 
start hacking on backports.

Thanks,
Brian Witte

Re: rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

[Johannes Berg]

Hi Brian,

> I spoke to Larry off list and considering the cfg80211 and mac80211 
> situation with older kernels further, he wants me to try and get a 
> simple backports setup validated so that people can still
> `make` and `make install`. 
> 

Sure. That should pretty much, after all, we do it many times every day
with iwlwifi with our internal tree :) But yeah, getting it generated
might take a bit of work.

> He is focused on a few other important tasks 
> and will probably get back with us here later, I just wanted to start 
> running downhill with this ASAP so I slid in here.

:)

> I am going to first try a variation of the approach you suggested where 
> I generate backports for Linux versions in the repo in ascending order 
> then have our Makefile detect user's version and install accordingly.

Wait, no, what? You don't need to detect the user's version or anything.

If you generate a single backports from say v6.6-rc6 today, users should
be able to run it on any kernel as far back as 4.something.

The only time you need _multiple_ backports is if you don't want to
stick to v6.6-rc6 (per example), but want to have v6.6-rc7 this week and
v6.6 release next week.

> Again, my understanding is often the bottleneck so I want to first say 
> what I intend to do and then ask a question:
> 
> 1. I want to use wireless-next as the upstream kernel source for 
> building the backports, I would need to build all backports via the 
> "package release" workflow [1]

Not sure I'd say that - the workflow page [1] is written with
instructions for your *users*, not for *you* as the one providing the
packages.

>  in order to provide users with a package 
> that they can use without needing the upstream source on their machine, 
> effectively giving them "a patch file" for compatibility for driver 
> specific modifications and the up-to-date 80211 stack. I would then only 
> need to decide which git tags for older kernels to use for the versions 
> we want to support, create the packages, then include those in the 
> repository.

Yes.

> [1] https://backports.wiki.kernel.org/index.php/Documentation/packaging

(just to keep the link)

> 2. I am trying to figure this out currently, but am not entirely sure 
> how granular the built package versions have to be in order to work with 
> a users kernel version. How do I decide the coverage of an individual 
> package per major-minor version or other variations? You mentioned RCs 
> earlier. For this first PoC, I want to make sure users can get the 
> driver working for any version they are running going back to 5.4.

No no, misunderstanding here I think. You don't need anything granular
at all, *all* your users should be able to use a *single* current
backports-based package.

The granularity question only comes in when you say have a user who
reports that something doesn't work. Now what, how do you get them to
e.g. bisect? Right now you have a git tree they can normally bisect in.

Now, if you
 - release backports tarballs for them to use, or
 - commit the output of backports into a git tree for them to use

*then* you get into the granularity question, which ends up being a
trade-off between what's effectively bisectability (you don't really
need to care about the history, after all, it's preserved upstream), and
effort on your end to generate (and test) them all.

> After that, our Makefile and/or scripts it coordinates will have to 
> detect the user version, then cd into that package, and install it 
> properly. 
> 

No, you should just give them the output of backports (gentree.py)
directly, it does all this.

> I am suspending any upstream commit history shenanigans for a 
> later point as making sure the driver is performant and in-line with the 
> up-to-date wireless stack.

OK, so then you just need to release a single tarball effectively.
Whether as a git branch or a literal tarball is pretty much irrelevant.

> Being able to use those features and have a 
> consistent API across the components is much more of a priority, at the 
> moment.
> 
> Thank you for you help and patience with all of this. You have helped 
> make this process an enjoyable thing to dive into and I am excited to 
> start hacking on backports.
> 

:)

johannes

Re: rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

[Johannes Berg]

> 
> > After that, our Makefile and/or scripts it coordinates will have to 
> > detect the user version, then cd into that package, and install it 
> > properly. 
> > 
> 
> No, you should just give them the output of backports (gentree.py)
> directly, it does all this.
> 

Well I phrased this badly - it doesn't of course "cd into that package"
etc, it's just a single package. However, it handles being compatible
with pretty much any kernel version.

johannes

Re: rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

[Brian Witte]

Johannes,

Thank you for quick reply.

> 
>> I am going to first try a variation of the approach you suggested where
>> I generate backports for Linux versions in the repo in ascending order
>> then have our Makefile detect user's version and install accordingly.
> 
> Wait, no, what? You don't need to detect the user's version or anything.
> 

Ah, yes! Ok, wow. Sorry. Things are finally adding up... ¬‿¬

> No no, misunderstanding here I think. You don't need anything granular
> at all, *all* your users should be able to use a *single* current
> backports-based package.
> 
> The granularity question only comes in when you say have a user who
> reports that something doesn't work. Now what, how do you get them to
> e.g. bisect? Right now you have a git tree they can normally bisect in.
> 
> Now, if you
>   - release backports tarballs for them to use, or
>   - commit the output of backports into a git tree for them to use
> 
> *then* you get into the granularity question, which ends up being a
> trade-off between what's effectively bisectability (you don't really
> need to care about the history, after all, it's preserved upstream), and
> effort on your end to generate (and test) them all.
> 

Right, yes.


>> After that, our Makefile and/or scripts it coordinates will have to
>> detect the user version, then cd into that package, and install it
>> properly.
>>
> 
> No, you should just give them the output of backports (gentree.py)
> directly, it does all this.
> 
>> I am suspending any upstream commit history shenanigans for a
>> later point as making sure the driver is performant and in-line with the
>> up-to-date wireless stack.
> 
> OK, so then you just need to release a single tarball effectively.
> Whether as a git branch or a literal tarball is pretty much irrelevant.
> 


Ok, I now understand.

I think because of the way I was trying to do things before I was 
failing to see how radically backports could simplify the task in many 
ways. The approach I have been using is far away from this way of doing 
things.

I am going to get started now.

Again, thank you for your patience and help.

Thanks,
Brian Witte

Re: rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

[Brian Witte]

> 
> I am going to get started now.
> 

Johannes,

Sorry for not getting back sooner. Busy at work, etc. then wanted to
make sure Larry could run the release package successfully.

I was able to get a new backports package built and running on my
machine over the weekend.

First, I did a `./gentree.py` on Hauke's v5.15.92 release with it's
corrresponding branch in stable with success and installed backports on
my hardware running v5.10.0. The new driver code was loaded and worked
as intended with a couple different usb dongles I have.

Second, as a test I built a package release for v5.16.20 because initial
rtw89 commit appears here:

  $ pwd
  /home/bkz/linux-stable

  $ git symbolic-ref --short HEAD && git rev-parse --short HEAD
  master
  ffc253263a13

  $ git describe --contains e3ec7017f6a20d12ddd9fe23d345ebb7b8c104dd
  v5.16-rc1~159^2~121^2~39

I was able to cut that release package that works for the rtw89 driver
by adjust existing patch file diff hunks to apply properly and adding a
new header that came in to net.

Preliminary test was successful:

  $ ./wi_stat.sh

  Kernel Version:
  5.10.0-26-amd64 debian

  Wireless Driver:
  device: wlp2s0
  driver: rtw89_pci

  Driver Stats:
  rx_bytes   : 359634613
  rx_packets : 271727
  tx_bytes   : 8117768
  tx_packets : 46573

My last question re: rtw89, since I just cut a release that "added it"
even though I did not do anything driver specific since the in-tree subsystem
and realtek/ dir do actual config, is this:

What other testing do you recommend for a "new driver" besides testing
"builds" as mentioned in docs [1] here in 'Adding new driver'?

It goes over supporting latest minor versions and says, "you should install
all supported kernel with the script in devel/get-compat-kernels and
then run devel/ckmake to build backports against every kernel version."

[1] https://backports.wiki.kernel.org/index.php/Documentation/backports/hacking

I am working on test/automation for our new backports workflow so any
insight you have would be helpful.

Again, thank you for your help. Larry and I appreciate it.

I will end this thread after your reply and come back to this list with
patches, general questions, and coordinating on helping cut new releases
for https://backports.wiki.kernel.org/index.php/Releases or updating
docs on the wiki.

Honestly, we could probably use some key points from this thread to make
some newbie friendly docs considering how confused I was at first, haha!

I could probably draw a nice diagram based on your explanations.

Anyway, thanks again!

Brian Witte

Re: rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

[Luis Chamberlain]

On Tue, Oct 31, 2023 at 05:24:04PM +0100, Brian Witte wrote:
> What other testing do you recommend for a "new driver" besides testing
> "builds" as mentioned in docs [1] here in 'Adding new driver'?

Whatever this ends up being:

> I am working on test/automation for our new backports workflow so any
> insight you have would be helpful.

If you decide to give kdevops a shot to allow folks to test wifi devices easily
I'm happy to give any tips / advice. PCIe passthrough is supported through
'make dynconfig' so you could end up using that so to not crash a host. We're
using that to test new block devices with new filesystem developments.
The only issue we've run into when doing this is when a PCI device resets
the sysfs file changes on the host so PCI passthrough stops, working
around this manually is documented here:

https://lore.kernel.org/all/ZQIRh+fpU1sR8BTN@bombadil.infradead.org/T/#u

How we fix this upstream for pcie passthrough remains unclear yet. For
wifi devices I am not sure what sort of things triggers full PCI device
resets, perhaps firmware crashes?

  Luis

Re: rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

[Brian Witte]

> From: Luis Chamberlain <mcgrof@kernel.org>
> Date: Oct 31, 2023, 2:36:46 PM
>
> If you decide to give kdevops a shot to allow folks to test wifi
> devices easily
> I'm happy to give any tips / advice. PCIe passthrough is supported through

Luis,

Yes, the plan is still kdevops for this.

At Linux Plumbers Conference, my main goals are:
1. Learn about kernel testing, debugging, and net/wireless.
2. Meet and get advice, tips from backports/wireless/kdevops folks.

I wanted to have kdevops set up in time for LPC so could I talk shop
better with other kdevops users, but figuring out how to get Larry's
most popular GitHub backport repos up-to-date took priority and I
stalled on the kdevops setup.

Right now I have a basic scripted QEMU setup that is a pain.

Good news is now that we have our ducks in a row with the gameplan for
using backports, I can jump back fully into testing workflow and
automation so we can start bumping up the release package versions that
work with rtw88/rtw89 to a more current stable. Larry thinks sticking to
stable will be better for the GitHub repos going forward with backports
instead of wireless-next like we were for the manual backports.

I will reach out on the kdevops channels as I go through it.

Thanks,

Brian Witte

Re: rtw88, rtw89 -- options for bringing a couple rtw standalone GitHub repos into backports.git

[Johannes Berg]

Hi Brian,

Sorry for the delay - had a bit of a crazy week last week.

> I was able to get a new backports package built and running on my
> machine over the weekend.

Nice :)

> First, I did a `./gentree.py` on Hauke's v5.15.92 release

I didn't even know there was a backports release of the scripts itself
rather than just the output ... :)

> with it's
> corrresponding branch in stable with success and installed backports on
> my hardware running v5.10.0. The new driver code was loaded and worked
> as intended with a couple different usb dongles I have.

Great! So progress, I guess :)

> Second, as a test I built a package release for v5.16.20 because initial
> rtw89 commit appears here:
> 
>   $ pwd
>   /home/bkz/linux-stable
> 
>   $ git symbolic-ref --short HEAD && git rev-parse --short HEAD
>   master
>   ffc253263a13
> 
>   $ git describe --contains e3ec7017f6a20d12ddd9fe23d345ebb7b8c104dd
>   v5.16-rc1~159^2~121^2~39
> 
> I was able to cut that release package that works for the rtw89 driver
> by adjust existing patch file diff hunks to apply properly and adding a
> new header that came in to net.

Right.

> What other testing do you recommend for a "new driver" besides testing
> "builds" as mentioned in docs [1] here in 'Adding new driver'?

Well if you have the devices, you could test them too, but ... if we
trust backports to more or less do the right thing, it should work :)

> It goes over supporting latest minor versions and says, "you should install
> all supported kernel with the script in devel/get-compat-kernels and
> then run devel/ckmake to build backports against every kernel version."
> 
> [1] https://backports.wiki.kernel.org/index.php/Documentation/backports/hacking
> 
> I am working on test/automation for our new backports workflow so any
> insight you have would be helpful.

Ah, well, that's more to make sure backports itself (as in the
compatibility code it adds and the changes it makes) actually compiles
against all the different kernels.

You might want to check that, and ckmake and all is just a nicer way of
achieving that. But you might want to restrict yourself to kernels that
you see actually in (broad) use from your users?

> Honestly, we could probably use some key points from this thread to make
> some newbie friendly docs considering how confused I was at first, haha!
> 
> I could probably draw a nice diagram based on your explanations.
> 

I wouldn't mind (you) adding something to the wiki but I'm not even sure
I know how to use it :)

johannes