-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Task / Story]: Transition wifi drivers to DKMS modules #6933
Comments
Jira ticket: AR-2416 |
In many cases this is done by 3rd party projects such as https://github.com/morrownr/USB-WiFi We bump commit ids and maintain a few of that are not covered by anyone else. For those few and a few end users that will get the same code in a different package?
Most users wants that WiFi works when they plug it in ... and on this idea this part of the Armbian is based upon. Practical way. Such ideas will always clash with developers perspectives. But at the end of the day, nobody really wants to compile drivers. If this is a serious problem, perhaps adding a disclaimers on download pages / welcome text? Most people are not aware of this. Also for vendor kernel are not clear what it is. For you and me, yes, for average Joe, no. We discussed option to drop those drivers in the past. Due to maintainace costs vs. real usability and actual needs. Common drivers should not be done by Armbian. We don't have capacity nor help from any WiFI vendor nor Linux foundation or similar organisation. This is where my fear lies. Wireless networking is serious problem / Pandora box.
Is this realistic to have this and keep it there on all default by user-space compilers? I am afraid not with all as upstream struggle already. Some we are dealing with in as-cheap-as-possible HW are broken beyond reasonable repair. This sounds like more work then now and providing something on higher levels. Without counting "getting there" part. I don't want to sound discouraging, or the one that wants to see the dark sides :) I need to see better rationale.
All those drivers should be tested after this. We need to be sure they are at least not working worse. Which is again more work for the team and something that require serious coordination to extract usable info and more to use that info. I tried to workaround this by building automated test station, but project is at hold for almost two years (as its yet again not that simple as it sounds) now and as there are so many other problems that also needs to be resolved ... If we go into any of this direction, lack of usable test automation is serious problem for R&D. Most of users will also never know we are doing anything (if there is no promotion about) and they will anyway report problems on various forums, Facebooks, 3rd party projects ... how to collect all this to know where you are and who will fix broken DKMS after? Which is new problem in this armbian-low-end-wireless drivers picture. Is it smaller or bigger then what it is now? |
Thanks for your reply!
Yes, that's a good thing that this exists at all. In theory, that doesn't sound "too hard to maintain". I can only talk from my own experience, I have enjoyed trying to bring boards to newer kernels. But sometimes the wifi drivers were a roadblock that stopped me from progressing for the actual kernel and board I was working on, because driver xy could not compile and so on. Not always, but when it did, it really sucked the joy out of working on that for me. I tried to make it a little bit easier to patch the drivers by adding URLs so you can just click on the link and are directly in the repo, and also added dates to the commits so you can compare the date of the commits instead of having to compare SHA hashes which aren't really meant to be compared by a human. But ultimately, this did not make the big difference I had hoped for. I'm sure that there are some maintainers who enjoy working on wifi drivers, so I'd like to leave this to them :)
Unfortunately I have to agree to this statement.
Raising awareness is always a good idea 👍
Yes, it is a similar pandora box like with the tv boxes. Maybe we should start by adding some recommended wifi adaptors to the website download section where people can see it? We can recommend actually good wifi adaptors (USB, M.2, ...) that are supported by mainline, where we don't have to do any maintenance. Users are happy because they have a good adaptor that just works and Armbian is happy because less issues 😄
Yeah, this is of course the other problem, vendors putting cheap unsupported wifi chipsets on some boards.
I don't want it to be more work or be more complex than it currently is, that seems like a step backwards 😅
Ahhh, it's never as simple as it sounds, I know 😅 But automation in general is the way :) More work in the beginning, but then way less work in the future (if done right). (Doesn't apply for everything of course) |
Few points here:
|
FTR, there is already a list: https://github.com/morrownr/USB-WiFi/blob/main/home/USB_WiFi_Adapters_that_are_supported_with_Linux_in-kernel_drivers.md#axe3000---usb30---24-ghz-5-ghz-and-6-ghz-wifi-6e |
Task description
The current status
Currently, 3rd-party wifi drivers cannot be installed on a per-board basis. Although some drivers are restricted to a specific LINUXFAMILY, many drivers are installed across all kernels. This approach leads to challenges because these drivers often require numerous patches (as shown in drivers_network.sh). These patches will frequently fail on new kernel versions and need to be carefully repaired, or new patches have to be crafted/imported.
This issue becomes particularly pronounced when updating to -rc kernel releases, such as those recently seen with the rk3588 family, where drivers may not yet be compatible with the latest kernel version.
Consequently, those who spend their time updating kernels to newer versions face an additional burden of fixing all the 3rd-party wifi drivers that might not be updated by their original maintainers
This ultimately means that the people who do lots of work to update kernels to newer versions are having this additional hurdle to jump over, to try and fix all the 3rd-party wifi drivers that may or may not be updated to the latest kernel version by their creators.
Proposed solution
Fix this by creating DKMS packages for the drivers which can then be installed on a per-board basis for boards with specific wifi chips or on-demand via the Armbian repo.
This approach offers several benefits:
Task list
NB: Anyone is welcome to take up this task and contribute to this description/task list :)
I do not plan to do this all on my own.
The text was updated successfully, but these errors were encountered: