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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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:

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

    $ 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

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

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux