On Wed, Jan 18, 2017 at 8:28 AM, Hans de Goede <hdegoede@xxxxxxxxxx> wrote: > Hi, > > > On 18-01-17 13:10, Josh Boyer wrote: > >> On Wed, Jan 18, 2017 at 5:18 AM, Hans de Goede <hdegoede@xxxxxxxxxx> >> 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 _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
