Hi All,
There are quite a few popular cheap x86 devices, such as the first gen Intel Compute Stick and many many ARM boards which have sdio wifi chips.
Unfortunately the mainline kernel lacks drivers for almost all sdio wifi chips, so Fedora ends up not supporting wifi on these devices, making it unattractive to run Fedora on these devices.
I want to fix this and I've been thinking about how to fix this. Options are:
a) A copr with kmod-s, this is not a good answer for 3 reasons: 1) It is a pain to maintain as it needs rebuilds each kernel build 2) It is not really a solution as copr does not build for ARM 3) On most of these devices wifi is the only network connectivity, so not having support on the install media makes it very hard to get wifi going to the point that an user will likely just give up
b) A copr with dkms modules, this is not a good answer for 2 reasons: 1) Building kernel modules from source on the users system is ugly and more importantly fragile 2) On most of these devices wifi is the only network connectivity, so not having support on the install media makes it very hard to get wifi going to the point that an user will likely just give up
c) Integrate the driver into the Fedora kernel pkg, which means that: 1) It will always be rebuild together with the kernel 2) It will be available at and directly after installation
d) Get the driver upstreamed. Unfortunately many of these drivers are vendor code, which often is ported windows code with lots of ugly glue; and the effort to get this upstream will take more time then I have to invest into this. Also if this were easy it would have been done by now, there are quite a few people interested in this. With this said I know that work is being done on upstreaming esp8089 support and the rtl8xxxu maintainer is looking on extending that with sdio support solving the problem for realtek chip. Note the ETA of any of this is unclear.
As such I've come to the conclusion that from a user pov the only really good solution is c.
As such I would like to (for starters) add this driver: https://github.com/hadess/rtl8723bs
Which is fully open source and although not ready for upstream, actively maintained by the community, to the driver/staging directory of the Fedora kernel pkg.
I realize this goes against the no out-of-tree kernel modules in Fedora rule, but I believe it is time we bend that rule a bit. IIRC that rule was made to disallow so called kmod packages, which as I've listed above indeed have a bunch of downsides. However I believe that by simply integrating the driver into the fedora kernel srpm we can avoid these issues.
I also believe that this rule goes against Fedora's basic principles:
-It goes against the First principle, many other distros are shipping with this driver -It goes against the Features principle, disallowing people to have working wifi is a mis-Feature -It goes against the Freedom principle, if a contributor is willing to spend time to maintain such a driver he/she should have the freedom to do so
I realize that this rule was made to protect the Fedora kernel maintainers from getting a lot of extra work on their plate caused by such drivers. But note that I'm not asking the Fedora kernel team to do any work on this, I'm volunteering to do both the integration work as well as maintaining these drivers going forward. If one a rebase to the next -rc1 things break, feel free to simply comment out the patch adding the driver(s) I will check each rc1 what the state is (test the driver on hardware with the specific sdio wifi chip) and fix any build or runtime issues, this is something which I'm doing anyways for my own kernel builds.
All I'm asking from the fedora kernel team is permission to add the driver.
Regards,
Hans
Lo! Three quick question from someone who for some strange reason is interested in this topic:
Hans de Goede wrote on 17.01.2017 13:11:
As such I would like to (for starters) add this driver: https://github.com/hadess/rtl8723bs
Which is fully open source and although not ready for upstream, actively maintained by the community, to the driver/staging directory of the Fedora kernel pkg.
* wouldn't it make more sense to simply add the driver to the staging directory upstream?
* will users somehow made aware they are using drivers of lower quality which are maintained differently (they for example might vanish suddenly if maintainers lose interest, which normally doesn't happen with proper kernel drivers)
* while at it: Is https://fedoraproject.org/wiki/KernelStagingPolicy still considered policy or is it a page everyone forgot about?
CU, knurd
Hi,
On 17-01-17 14:12, Thorsten Leemhuis wrote:
Lo! Three quick question from someone who for some strange reason is interested in this topic:
Hans de Goede wrote on 17.01.2017 13:11:
As such I would like to (for starters) add this driver: https://github.com/hadess/rtl8723bs
Which is fully open source and although not ready for upstream, actively maintained by the community, to the driver/staging directory of the Fedora kernel pkg.
- wouldn't it make more sense to simply add the driver to the staging
directory upstream?
See my answer to Bastien's mail.
- will users somehow made aware they are using drivers of lower quality
which are maintained differently (they for example might vanish suddenly if maintainers lose interest, which normally doesn't happen with proper kernel drivers)
Other then the standard tainting caused by this being in staging, no.
- while at it: Is https://fedoraproject.org/wiki/KernelStagingPolicy
still considered policy or is it a page everyone forgot about?
I for one had never heard about that page.
Regards,
Hans
On 01/17/2017 05:19 AM, Hans de Goede wrote:
Hi,
On 17-01-17 14:12, Thorsten Leemhuis wrote:
Lo! Three quick question from someone who for some strange reason is interested in this topic:
Hans de Goede wrote on 17.01.2017 13:11:
As such I would like to (for starters) add this driver: https://github.com/hadess/rtl8723bs
Which is fully open source and although not ready for upstream, actively maintained by the community, to the driver/staging directory of the Fedora kernel pkg.
- wouldn't it make more sense to simply add the driver to the staging
directory upstream?
See my answer to Bastien's mail.
- will users somehow made aware they are using drivers of lower quality
which are maintained differently (they for example might vanish suddenly if maintainers lose interest, which normally doesn't happen with proper kernel drivers)
Other then the standard tainting caused by this being in staging, no.
- while at it: Is https://fedoraproject.org/wiki/KernelStagingPolicy
still considered policy or is it a page everyone forgot about?
I for one had never heard about that page.
Regards,
Hans
Yes, that page should still be accurate wrt to staging policy although I think the list of drivers might need to be updated.
In general, I think upstreaming is the right approach to take and if you are willing to go through staging, I think that could be a good path to work to get the driver out of staging.
Thanks, Laura
Hi,
On 17-01-17 21:59, Laura Abbott wrote:
On 01/17/2017 05:19 AM, Hans de Goede wrote:
Hi,
On 17-01-17 14:12, Thorsten Leemhuis wrote:
Lo! Three quick question from someone who for some strange reason is interested in this topic:
Hans de Goede wrote on 17.01.2017 13:11:
As such I would like to (for starters) add this driver: https://github.com/hadess/rtl8723bs
Which is fully open source and although not ready for upstream, actively maintained by the community, to the driver/staging directory of the Fedora kernel pkg.
- wouldn't it make more sense to simply add the driver to the staging
directory upstream?
See my answer to Bastien's mail.
- will users somehow made aware they are using drivers of lower quality
which are maintained differently (they for example might vanish suddenly if maintainers lose interest, which normally doesn't happen with proper kernel drivers)
Other then the standard tainting caused by this being in staging, no.
- while at it: Is https://fedoraproject.org/wiki/KernelStagingPolicy
still considered policy or is it a page everyone forgot about?
I for one had never heard about that page.
Regards,
Hans
Yes, that page should still be accurate wrt to staging policy although I think the list of drivers might need to be updated.
In general, I think upstreaming is the right approach to take and if you are willing to go through staging, I think that could be a good path to work to get the driver out of staging.
I've the feeling this whole discussion has been derailed a bit by focusing too much on the rtl8723bs example.
Quoting from my original mail, upstreaming was given as one possible solution:
"d) Get the driver upstreamed. Unfortunately many of these drivers are vendor code, which often is ported windows code with lots of ugly glue; and the effort to get this upstream will take more time then I have to invest into this. Also if this were easy it would have been done by now, there are quite a few people interested in this."
Nothing has changed wrt this, to be specific I would like to see the following wifi drivers be available in Fedora kernels:
rtl8723bs rtl8189es rtl8189fs esp8089 xradio
And in the future possible others (rda599x comes to mind) and I simply do not have the bandwidth to get 1 one of these let alone all of these into staging, let alone fully mainlined.
Currently we're crippling our user experience by refusing to ship drivers support this hardware even though there are fully open drivers to support these.
Again quoting from my original email:
"I also believe that this rule goes against Fedora's basic principles:
-It goes against the First principle, many other distros are shipping with this driver -It goes against the Features principle, disallowing people to have working wifi is a mis-Feature -It goes against the Freedom principle, if a contributor is willing to spend time to maintain such a driver he/she should have the freedom to do so"
And I still end up at my original unanswered question:
"All I'm asking from the fedora kernel team is permission to add the driver."
Regards,
Hans
On Wed, Jan 18, 2017 at 5:18 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 17-01-17 21:59, Laura Abbott wrote:
On 01/17/2017 05:19 AM, Hans de Goede wrote:
Hi,
On 17-01-17 14:12, Thorsten Leemhuis wrote:
Lo! Three quick question from someone who for some strange reason is interested in this topic:
Hans de Goede wrote on 17.01.2017 13:11:
As such I would like to (for starters) add this driver: https://github.com/hadess/rtl8723bs
Which is fully open source and although not ready for upstream, actively maintained by the community, to the driver/staging directory of the Fedora kernel pkg.
- wouldn't it make more sense to simply add the driver to the staging
directory upstream?
See my answer to Bastien's mail.
- will users somehow made aware they are using drivers of lower quality
which are maintained differently (they for example might vanish suddenly if maintainers lose interest, which normally doesn't happen with proper kernel drivers)
Other then the standard tainting caused by this being in staging, no.
- while at it: Is https://fedoraproject.org/wiki/KernelStagingPolicy
still considered policy or is it a page everyone forgot about?
I for one had never heard about that page.
Regards,
Hans
Yes, that page should still be accurate wrt to staging policy although I think the list of drivers might need to be updated.
In general, I think upstreaming is the right approach to take and if you are willing to go through staging, I think that could be a good path to work to get the driver out of staging.
I've the feeling this whole discussion has been derailed a bit by focusing too much on the rtl8723bs example.
Quoting from my original mail, upstreaming was given as one possible solution:
"d) Get the driver upstreamed. Unfortunately many of these drivers are vendor code, which often is ported windows code with lots of ugly glue; and the effort to get this upstream will take more time then I have to invest into this. Also if this were easy it would have been done by now, there are quite a few people interested in this."
Nothing has changed wrt this, to be specific I would like to see the following wifi drivers be available in Fedora kernels:
rtl8723bs rtl8189es rtl8189fs esp8089 xradio
And in the future possible others (rda599x comes to mind) and I simply do not have the bandwidth to get 1 one of these let alone all of these into staging, let alone fully mainlined.
Currently we're crippling our user experience by refusing to ship drivers support this hardware even though there are fully open drivers to support these.
Hans, I think you need to take a deep breath. You seem to have come to this discussion with fully loaded guns blazing.
Nobody has refused your request. There's been a discussion about the best way to get it upstream. Nobody has said no.
Also, I understand your argumentation about user experience but this is the first I've heard of this issue and I couldn't find any reports of this in bugzilla. While it isn't relevant to the decision to add the drivers, I do wonder how many users we have of such hardware. It seems we aren't crippling user experience as much as we would be making it possible to use the hardware in the first place. That could certainly be a good thing.
Again quoting from my original email:
"I also believe that this rule goes against Fedora's basic principles:
-It goes against the First principle, many other distros are shipping with this driver -It goes against the Features principle, disallowing people to have working wifi is a mis-Feature -It goes against the Freedom principle, if a contributor is willing to spend time to maintain such a driver he/she should have the freedom to do so"
Principles are good to have and provide guidance on how one should act when possible. Sometimes they're out-weighed by reality though. I mean, if we were to take them literally for every single issue, we'd be supporting armv5, armv6, sparc, mips, mips64, etc etc. That's not hyperbole either. Users have requested all of those. The team simply doesn't have the resources to do them all. I know you know this, so throwing principles in the Fedora kernel team's face seems a little preachy just for the sake of getting what you want.
And I still end up at my original unanswered question:
"All I'm asking from the fedora kernel team is permission to add the driver."
I believe you also offered to maintain it, yes? I have no say in this decision, but that's going to be a key detail.
josh
Hi,
On 18-01-17 13:10, Josh Boyer wrote:
On Wed, Jan 18, 2017 at 5:18 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 17-01-17 21:59, Laura Abbott wrote:
On 01/17/2017 05:19 AM, Hans de Goede wrote:
Hi,
On 17-01-17 14:12, Thorsten Leemhuis wrote:
Lo! Three quick question from someone who for some strange reason is interested in this topic:
Hans de Goede wrote on 17.01.2017 13:11:
As such I would like to (for starters) add this driver: https://github.com/hadess/rtl8723bs
Which is fully open source and although not ready for upstream, actively maintained by the community, to the driver/staging directory of the Fedora kernel pkg.
- wouldn't it make more sense to simply add the driver to the staging
directory upstream?
See my answer to Bastien's mail.
- will users somehow made aware they are using drivers of lower quality
which are maintained differently (they for example might vanish suddenly if maintainers lose interest, which normally doesn't happen with proper kernel drivers)
Other then the standard tainting caused by this being in staging, no.
- while at it: Is https://fedoraproject.org/wiki/KernelStagingPolicy
still considered policy or is it a page everyone forgot about?
I for one had never heard about that page.
Regards,
Hans
Yes, that page should still be accurate wrt to staging policy although I think the list of drivers might need to be updated.
In general, I think upstreaming is the right approach to take and if you are willing to go through staging, I think that could be a good path to work to get the driver out of staging.
I've the feeling this whole discussion has been derailed a bit by focusing too much on the rtl8723bs example.
Quoting from my original mail, upstreaming was given as one possible solution:
"d) Get the driver upstreamed. Unfortunately many of these drivers are vendor code, which often is ported windows code with lots of ugly glue; and the effort to get this upstream will take more time then I have to invest into this. Also if this were easy it would have been done by now, there are quite a few people interested in this."
Nothing has changed wrt this, to be specific I would like to see the following wifi drivers be available in Fedora kernels:
rtl8723bs rtl8189es rtl8189fs esp8089 xradio
And in the future possible others (rda599x comes to mind) and I simply do not have the bandwidth to get 1 one of these let alone all of these into staging, let alone fully mainlined.
Currently we're crippling our user experience by refusing to ship drivers support this hardware even though there are fully open drivers to support these.
Hans, I think you need to take a deep breath. You seem to have come to this discussion with fully loaded guns blazing.
Nobody has refused your request. There's been a discussion about the best way to get it upstream. Nobody has said no.
Also, I understand your argumentation about user experience but this is the first I've heard of this issue and I couldn't find any reports of this in bugzilla. While it isn't relevant to the decision to add the drivers, I do wonder how many users we have of such hardware. It seems we aren't crippling user experience as much as we would be making it possible to use the hardware in the first place. That could certainly be a good thing.
Again quoting from my original email:
"I also believe that this rule goes against Fedora's basic principles:
-It goes against the First principle, many other distros are shipping with this driver -It goes against the Features principle, disallowing people to have working wifi is a mis-Feature -It goes against the Freedom principle, if a contributor is willing to spend time to maintain such a driver he/she should have the freedom to do so"
Principles are good to have and provide guidance on how one should act when possible. Sometimes they're out-weighed by reality though. I mean, if we were to take them literally for every single issue, we'd be supporting armv5, armv6, sparc, mips, mips64, etc etc. That's not hyperbole either. Users have requested all of those. The team simply doesn't have the resources to do them all. I know you know this, so throwing principles in the Fedora kernel team's face seems a little preachy just for the sake of getting what you want.
Heh, I actually mentioned them because I was afraid that the principle of upstream first was getting in the way of the reality being that sometimes drivers are hard to upstream, yet users still need them.
I've always liked Fedora for its pragmatic approach to things, e.g. see how we deal with wifi firmware vs how Debian does.
And I still end up at my original unanswered question:
"All I'm asking from the fedora kernel team is permission to add the driver."
I believe you also offered to maintain it, yes?
Yes, if I get to go ahead to add these I will take care of them 100%, which is also why I want to start with just rtl8723bs and see how that goes.
As said the Fedora kernel team can just comment out the patches when things break when rebasing to a new rc1, and I will take care of getting things fixed. Note if things break in a minor release e.g. going from 4.8.15 to 4.8.16 a heads-up of course would be appreciated, but I assume that is common sense.
Regards,
Hans
On Wed, Jan 18, 2017 at 9:28 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 18-01-17 13:10, Josh Boyer wrote:
On Wed, Jan 18, 2017 at 5:18 AM, Hans de Goede hdegoede@redhat.com
And I still end up at my original unanswered question:
"All I'm asking from the fedora kernel team is permission to add the driver."
I believe you also offered to maintain it, yes?
Yes, if I get to go ahead to add these I will take care of them 100%, which is also why I want to start with just rtl8723bs and see how that goes.
As said the Fedora kernel team can just comment out the patches when things break when rebasing to a new rc1, and I will take care of getting things fixed. Note if things break in a minor release e.g. going from 4.8.15 to 4.8.16 a heads-up of course would be appreciated, but I assume that is common sense.
We did this with another out-of-tree patchset a while ago to support ACPI and UEFI on Aarch64 before that was upstream. The maintainer of that patchset did a great job and I think it worked well enough. As I said earlier, I don't have a say in the decision but if similar efforts are in place for these drivers then it could be successful.
josh
On Wed, Jan 18, 2017 at 8:28 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 18-01-17 13:10, Josh Boyer wrote:
On Wed, Jan 18, 2017 at 5:18 AM, Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 17-01-17 21:59, Laura Abbott wrote:
On 01/17/2017 05:19 AM, Hans de Goede wrote:
Hi,
On 17-01-17 14:12, Thorsten Leemhuis wrote:
Lo! Three quick question from someone who for some strange reason is interested in this topic:
Hans de Goede wrote on 17.01.2017 13:11:
> > > As such I would like to (for starters) add this driver: > https://github.com/hadess/rtl8723bs > > Which is fully open source and although not ready for > upstream, actively maintained by the community, to the > driver/staging directory of the Fedora kernel pkg. >
- wouldn't it make more sense to simply add the driver to the staging
directory upstream?
See my answer to Bastien's mail.
- will users somehow made aware they are using drivers of lower quality
which are maintained differently (they for example might vanish suddenly if maintainers lose interest, which normally doesn't happen with proper kernel drivers)
Other then the standard tainting caused by this being in staging, no.
- while at it: Is https://fedoraproject.org/wiki/KernelStagingPolicy
still considered policy or is it a page everyone forgot about?
I for one had never heard about that page.
Regards,
Hans
Yes, that page should still be accurate wrt to staging policy although I think the list of drivers might need to be updated.
In general, I think upstreaming is the right approach to take and if you are willing to go through staging, I think that could be a good path to work to get the driver out of staging.
I've the feeling this whole discussion has been derailed a bit by focusing too much on the rtl8723bs example.
Quoting from my original mail, upstreaming was given as one possible solution:
"d) Get the driver upstreamed. Unfortunately many of these drivers are vendor code, which often is ported windows code with lots of ugly glue; and the effort to get this upstream will take more time then I have to invest into this. Also if this were easy it would have been done by now, there are quite a few people interested in this."
Nothing has changed wrt this, to be specific I would like to see the following wifi drivers be available in Fedora kernels:
rtl8723bs rtl8189es rtl8189fs esp8089 xradio
And in the future possible others (rda599x comes to mind) and I simply do not have the bandwidth to get 1 one of these let alone all of these into staging, let alone fully mainlined.
Currently we're crippling our user experience by refusing to ship drivers support this hardware even though there are fully open drivers to support these.
Hans, I think you need to take a deep breath. You seem to have come to this discussion with fully loaded guns blazing.
Nobody has refused your request. There's been a discussion about the best way to get it upstream. Nobody has said no.
Also, I understand your argumentation about user experience but this is the first I've heard of this issue and I couldn't find any reports of this in bugzilla. While it isn't relevant to the decision to add the drivers, I do wonder how many users we have of such hardware. It seems we aren't crippling user experience as much as we would be making it possible to use the hardware in the first place. That could certainly be a good thing.
Again quoting from my original email:
"I also believe that this rule goes against Fedora's basic principles:
-It goes against the First principle, many other distros are shipping with this driver -It goes against the Features principle, disallowing people to have working wifi is a mis-Feature -It goes against the Freedom principle, if a contributor is willing to spend time to maintain such a driver he/she should have the freedom to do so"
Principles are good to have and provide guidance on how one should act when possible. Sometimes they're out-weighed by reality though. I mean, if we were to take them literally for every single issue, we'd be supporting armv5, armv6, sparc, mips, mips64, etc etc. That's not hyperbole either. Users have requested all of those. The team simply doesn't have the resources to do them all. I know you know this, so throwing principles in the Fedora kernel team's face seems a little preachy just for the sake of getting what you want.
Heh, I actually mentioned them because I was afraid that the principle of upstream first was getting in the way of the reality being that sometimes drivers are hard to upstream, yet users still need them.
I've always liked Fedora for its pragmatic approach to things, e.g. see how we deal with wifi firmware vs how Debian does.
And I still end up at my original unanswered question:
"All I'm asking from the fedora kernel team is permission to add the driver."
I believe you also offered to maintain it, yes?
Yes, if I get to go ahead to add these I will take care of them 100%, which is also why I want to start with just rtl8723bs and see how that goes.
As said the Fedora kernel team can just comment out the patches when things break when rebasing to a new rc1, and I will take care of getting things fixed. Note if things break in a minor release e.g. going from 4.8.15 to 4.8.16 a heads-up of course would be appreciated, but I assume that is common sense.
I spent a bit of time considering this yesterday, and honestly couldn't
find a workable solution outside of adding them to the kernel. Being network drivers, it would be hard to put them elsewhere. I really don't like taking them without a definite upstream path in site. We appreciate that you are willing to maintain them, so go ahead and add them. We will give you a heads up if we find anything with them.
Thanks, Justin
Hi,
On 18-01-17 17:55, Justin Forbes wrote:
On Wed, Jan 18, 2017 at 8:28 AM, Hans de Goede <hdegoede@redhat.com mailto:hdegoede@redhat.com> wrote:
Hi, On 18-01-17 13:10, Josh Boyer wrote:
<snip>
rtl8723bs rtl8189es rtl8189fs esp8089 xradio And in the future possible others (rda599x comes to mind) and I simply do not have the bandwidth to get 1 one of these let alone all of these into staging, let alone fully mainlined. Currently we're crippling our user experience by refusing to ship drivers support this hardware even though there are fully open drivers to support these. Hans, I think you need to take a deep breath. You seem to have come to this discussion with fully loaded guns blazing. Nobody has refused your request. There's been a discussion about the best way to get it upstream. Nobody has said no. Also, I understand your argumentation about user experience but this is the first I've heard of this issue and I couldn't find any reports of this in bugzilla. While it isn't relevant to the decision to add the drivers, I do wonder how many users we have of such hardware.
The rtl8723bs driver is needed for a lot (I guesstimate over half of all models) baytrail / cherrytrail hardware out there, as well as quite a few ARM boards.
The rtl8189es, rtl8189fs and xradio drivers are necessary for wifi support on the relatively popular orangepi ARM boards (different variants use a different wifi chip).
Currently AFAIK most orangepi users are using armbian, because that comes with a patches kernel adding support for various peripherals of which wifi is the most prominent for headless use cases (and unfortunatelt the one with the least progress upstream).
The esp8089 is mainly found in some Allwinner ARM tablets (which can run mainline), it needs some work to the mmc core which needs to be mainlined first; and of all drivers it actually has the clearest path to get into mainline as free-electrons is working on mainlining it.
It seems we aren't crippling user experience as much as we would be making it possible to use the hardware in the first place. That could certainly be a good thing.
Ack.
<snip>
And I still end up at my original unanswered question: "All I'm asking from the fedora kernel team is permission to add the driver." I believe you also offered to maintain it, yes? Yes, if I get to go ahead to add these I will take care of them 100%, which is also why I want to start with just rtl8723bs and see how that goes. As said the Fedora kernel team can just comment out the patches when things break when rebasing to a new rc1, and I will take care of getting things fixed. Note if things break in a minor release e.g. going from 4.8.15 to 4.8.16 a heads-up of course would be appreciated, but I assume that is common sense.
I spent a bit of time considering this yesterday, and honestly couldn't find a workable solution outside of adding them to the kernel. Being network drivers, it would be hard to put them elsewhere. I really don't like taking them without a definite upstream path in site. We appreciate that you are willing to maintain them, so go ahead and add them. We will give you a heads up if we find anything with them.
Ok, thank you!
Bastien I would like to start with adding the rtl8723bs driver (which we can hopefully drop soon again, assuming getting it into mainline-staging works out). Is that ok with you ?
Regards,
Hans
On 01/18/2017 02:18 AM, Hans de Goede wrote:
Hi,
On 17-01-17 21:59, Laura Abbott wrote:
On 01/17/2017 05:19 AM, Hans de Goede wrote:
Hi,
On 17-01-17 14:12, Thorsten Leemhuis wrote:
Lo! Three quick question from someone who for some strange reason is interested in this topic:
Hans de Goede wrote on 17.01.2017 13:11:
As such I would like to (for starters) add this driver: https://github.com/hadess/rtl8723bs
Which is fully open source and although not ready for upstream, actively maintained by the community, to the driver/staging directory of the Fedora kernel pkg.
- wouldn't it make more sense to simply add the driver to the staging
directory upstream?
See my answer to Bastien's mail.
- will users somehow made aware they are using drivers of lower quality
which are maintained differently (they for example might vanish suddenly if maintainers lose interest, which normally doesn't happen with proper kernel drivers)
Other then the standard tainting caused by this being in staging, no.
- while at it: Is https://fedoraproject.org/wiki/KernelStagingPolicy
still considered policy or is it a page everyone forgot about?
I for one had never heard about that page.
Regards,
Hans
Yes, that page should still be accurate wrt to staging policy although I think the list of drivers might need to be updated.
In general, I think upstreaming is the right approach to take and if you are willing to go through staging, I think that could be a good path to work to get the driver out of staging.
I've the feeling this whole discussion has been derailed a bit by focusing too much on the rtl8723bs example.
Quoting from my original mail, upstreaming was given as one possible solution:
Yes, and I think it's the best solution and should still be pursued in parallel.
"d) Get the driver upstreamed. Unfortunately many of these drivers are vendor code, which often is ported windows code with lots of ugly glue; and the effort to get this upstream will take more time then I have to invest into this. Also if this were easy it would have been done by now, there are quite a few people interested in this."
Nothing has changed wrt this, to be specific I would like to see the following wifi drivers be available in Fedora kernels:
rtl8723bs rtl8189es rtl8189fs esp8089 xradio
And in the future possible others (rda599x comes to mind) and I simply do not have the bandwidth to get 1 one of these let alone all of these into staging, let alone fully mainlined.
Currently we're crippling our user experience by refusing to ship drivers support this hardware even though there are fully open drivers to support these.
And that's the problem. This happens all the time with kernel drivers, everyone wants the end result of a driver but the work to actually make it sustainable never gets done. Unless a driver is actually merged in the upstream kernel, it's not going to work in the long term. Keeping the driver out of tree means it loses out on review and updates coming from the kernel community which is better for the driver in the long term.
Again quoting from my original email:
"I also believe that this rule goes against Fedora's basic principles:
-It goes against the First principle, many other distros are shipping with this driver -It goes against the Features principle, disallowing people to have working wifi is a mis-Feature -It goes against the Freedom principle, if a contributor is willing to spend time to maintain such a driver he/she should have the freedom to do so"
I really have to disagree with most of this here.
First doesn't mean just being the very first for everything. It's possible for features to be available out there somewhere but not yet ready for distribution. Other distributions have different requirements and their idea of ready may not be Fedora's idea. (e.g. BTRFS as default)
From https://fedoraproject.org/wiki/Foundations
"We also believe that these changes are best developed in direct concert with the upstream software communities whose work is part of the Fedora distribution."
I'd rather see Fedora be the first to make an effort to get the driver upstream.
Finally I really don't see the issue of freedom here. Nobody is saying you can't maintain the driver yourself in another repo or take the Fedora tree and distribute it yourself with extra modules added, several of the options you proposed involved exactly that. The discussion here is if the driver belongs as part of the maintained Fedora kernel. I do not believe it is a violation of free software to have a discussion and say no to a feature, even if someone is willing to maintain it.
And I still end up at my original unanswered question:
"All I'm asking from the fedora kernel team is permission to add the driver."
Justin's response there stands but I still firmly believe that actively working to get the driver upstreamed is in Fedora's best interest for the long term.
Regards,
Hans
Thanks, Laura
And that's the problem. This happens all the time with kernel drivers, everyone wants the end result of a driver but the work to actually make it sustainable never gets done. Unless a driver is actually merged in the upstream kernel, it's not going to work in the long term. Keeping the driver out of tree means it loses out on review and updates coming from the kernel community which is better for the driver in the long term.
I've no horse in this race, but I've maintained things in the Fedora kernel, and it's a losing game, you'll get bored keeping up with it.
As for staging, the path out of staging can be that another driver will subsume the functionality and then this driver will be removed, afaik we did this for some drivers before.
However I don't think we should be taking on any downstream responsiblity for drivers we aren't willing to spend time on getting upstream, it gives people less reason to bother doing things properly.
Dave.
Hi,
Currently we're crippling our user experience by refusing to ship drivers support this hardware even though there are fully open drivers to support these.
And that's the problem. This happens all the time with kernel drivers, everyone wants the end result of a driver but the work to actually make it sustainable never gets done. Unless a driver is actually merged in the upstream kernel, it's not going to work in the long term.
I'd say it is fine to include out-of-tree drivers in case there is
(a) is someone maintaining the patches (which Hans promised to do here), and (b) there is a plan for upstream supporting the hardware, so we don't end up maintaining these patches forever.
And IMO both "someone actively works on upstreaming the driver" and "support for this hardware will be added to another driver (such as rtl8xxxu)" are good as upstream plan.
cheers, Gerd
kernel@lists.fedoraproject.org