Greg, folks,
So the staging area of the Linux kernel has proven quite successful
for a few drivers for 802.11 already. Otus [0] for example was
rewritten completely first as ar9170 [1] and then carl9170 [2] even
with open firmware, carl9170.fw [3] and then Otus got nuked. ath6kl
[4] is another example, it got a lot of heavy handing on staging and
then Kalle took over and decided to work on the tree outside of the
kernel given that he was actually familiar with upstream requirements,
he just needed a lot more freedom than what we allow for patches
upstream to do a lot of heavy handing cleanup.
So staging helps a lot with drivers that likely get a little attention
or to help educate developers or vendors not used to upstream
development, but for experienced upstream developers that don't need
these lessons its a bit of a arm twister (although still good
practice) to deal with the requirements of patches upstream for a huge
cleanup. Granted keeping the history is good and important, specially
if accepting patches and so on, but at least from what I'm seeing some
802.11 developers are preferring to do the staging outside of the
Linux kernel. For both of these drivers then the main usage of staging
was as immediate enablement for users given that otherwise other Linux
distributions would cherry pick these drivers anyway and stable fixes
for these users, but for development experienced 802.11 developers
have used it only as a base to fork and do major overhauls. That was
the case for both otus and ath6kl and from the looks of it it seems
that the same is being preferred for the wcn36xx driver [5] which is a
clean rewrite of prima driver [6]. There are also some drivers on my
radar that I think might take similar approach, but not because they
are crap but still because they are still real staging drivers.
Despite these things some folks may want them. For example the
Wilocity 60 GHz 802.11ad wil6210 [8] driver was desired just for
monitor mode support as soon as that was supported and we wanted those
folks to be able to get it through a unified, and yet
upstream-prioritizing-friendly-fassion. Obviously no one runs the
latest foo-next subsystem kernels unless you are a developer so we
backport these drivers through compat-drivers [7]. For a while I
accepted these drivers into compat-drivers as a patch under crap/ with
the caveat that I'd kick them out after a kernel release or two if
they were not upstream by then. The maintenance of such drivers proved
painful, so I decided to kick them all out and push everyone to
usptream ASAP. That worked for wil6210, now upstrea, but for the
Ethernet alx driver [9], based on community feedback, still requires
more work. The crux of the alx driver was to either go to staging or
keep it externally for whatever reason. I was fan of just getting it
under staging but at that point I started addressing driver code
quality in general at corporations with Adrian [10] who works on
FreeBSD. If we can address code quality at large from inception, from
bring up code, then we'd all be in a better place. This experience has
been very educational given that it has brought up general bring up
considerations and timeline considerations for code and hardware. We
have to separate all these. We are currently testing an idea to use a
unified driver strategy for both FreeBSD and Linux under a unified
driver git tree for both which would never put in compromise the
upstream requirements for both. The idea is to do the staging
development companies typically do on their end publicly and address
their idea of unification *with* the community [11]. We chose alx
given the simplicity of the driver but work is going slow there. While
we give some time for that work to brew I have integrated it to
compat-drivers by extracting code using a reference git tree, this
lets the driver always have to deal with only linux-next being the
target and we'd deal with the backporting through compat-drivers and
compat. I will kick the alx driver out of compat-drivers though if we
don't get any unification interest from FreeBSD though, but this
experience has helped so far.
The issue of staging and bring up still exists and another drivers is
on the roadmap that is already sort of upstream quality but developers
would prefer to do development outside of drivers/staging/ to simply
address proper upstream as an ultimate objective given the major
overhauls required still and given the developers involved are
experienced upstream developers. The question of enablement to end
users of that driver comes up and I now have to consider adding cherry
picking drivers of that type to compat-drivers or simply asking for
folks to wait until its upstream. This has me thinking if it makes
sense to have an external driver tree for staging drivers but lead by
engineers who already know the rules of upstream, they just want to
get things done faster. Wanted to get your and the community's
feedback on this.
[0] http://wireless.kernel.org/en/users/Drivers/otus
[1] http://wireless.kernel.org/en/users/Drivers/ar9170
[2] http://wireless.kernel.org/en/users/Drivers/carl9170
[3] http://wireless.kernel.org/en/users/Drivers/carl9170.fw
[4] http://wireless.kernel.org/en/users/Drivers/ath6kl
[5] https://github.com/KrasnikovEugene/wcn36xx
[6] https://www.codeaurora.org/gitweb/external/wlan/?p=prima.git
[7] https://backports.wiki.kernel.org
[8] http://wireless.kernel.org/en/users/Drivers/wil6210
[9] http://www.linuxfoundation.org/collaborate/workgroups/networking/alx
[10] http://www.do-not-panic.com/2013/03/killing-proprietary-drivers-for-all.html
[11] http://lists.infradead.org/mailman/listinfo/unified-drivers
Luis
On Thu, Mar 28, 2013 at 3:53 PM, Greg Kroah-Hartman
<[email protected]> wrote:
> On Thu, Mar 28, 2013 at 01:13:23PM -0700, Luis R. Rodriguez wrote:
>
> <huge snip>
>
>> This has me thinking if it makes sense to have an external driver tree
>> for staging drivers but lead by engineers who already know the rules
>> of upstream, they just want to get things done faster.
>
> That's called a "fork" or "tree" or whatever you want to call it, and
> all of us have them, and end up merging stuff to mainline through them
> eventually.
>
> There is no need to "codify" something that we all have been doing for
> years. If someone thinks they can "work faster" in their own tree,
> great for them, have them do it. I don't see what I need to agree or
> disagree with here to keep anyone from doing such a thing.
>
> Or am I just totally missing something here?
OK, yes I think we can work better if we had an external trees for
each driver to cherry pick them as they get sanitized, prior to
upstream for *some* drivers. Very well. I'll simply let vendors /
developers get their 802.11 driver as part of compat-drivers so long
as they maintain their poo.
Luis
On Thu, Mar 28, 2013 at 01:13:23PM -0700, Luis R. Rodriguez wrote:
<huge snip>
> This has me thinking if it makes sense to have an external driver tree
> for staging drivers but lead by engineers who already know the rules
> of upstream, they just want to get things done faster.
That's called a "fork" or "tree" or whatever you want to call it, and
all of us have them, and end up merging stuff to mainline through them
eventually.
There is no need to "codify" something that we all have been doing for
years. If someone thinks they can "work faster" in their own tree,
great for them, have them do it. I don't see what I need to agree or
disagree with here to keep anyone from doing such a thing.
Or am I just totally missing something here?
greg k-h