From: Greg KH <greg@kroah.com>
To: "Luis R. Rodriguez" <mcgrof@gmail.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jouni Malinen <j@w1.fi>, Sujith <m.sujith@gmail.com>,
Sujith <Sujith.Manoharan@atheros.com>,
Senthilkumar Balasubramanian
<Senthilkumar.Balasubramanian@atheros.com>,
Johannes Berg <johannes@sipsolutions.net>,
"John W. Linville" <linville@tuxdriver.com>,
Christoph Hellwig <hch@infradead.org>,
Vasanthakumar Thiagarajan <vasanth@atheros.com>
Subject: Re: Staging, place holder for better company/community development model
Date: Mon, 2 Mar 2009 23:30:45 -0800 [thread overview]
Message-ID: <20090303073045.GA4528@kroah.com> (raw)
In-Reply-To: <43e72e890903022314o44ae710u834d6207403fd4a2@mail.gmail.com>
On Mon, Mar 02, 2009 at 11:14:56PM -0800, Luis R. Rodriguez wrote:
> A lot of people really hate the staging tree.
They do? I've not gotten any complaints that I can remember about it.
> I don't but let me tell you why and I'd like to see if you concur with
> these particular concrete use cases and ideas on how to further use
> it.
>
> The ath9k driver came to many as a big surprise -- and since it was a
> surprise we had to do the work ourselves as a team at Atheros in
> closed doors, without the community's involvement until we got
> something standing up and not smelling as bad. Our own change in
> direction to work on things upstream can be seen later as well by the
> release of the 11n Otus driver and documentation provided to
> interested developers to port it to mac80211 (not to mention similar
> type of work for ath5k) -- Johannes quickly then ported it and created
> the ar9170 11n USB driver which is its replacement for otus and
> targeted for wireless-testing. Otus is currently part of the staging
> tree. While ar9170 has no 802.11n support users wishing to test 11n
> USB with an open driver can use the "vendor" driver. The idea is to
> minimize as time goes by the "port" effort and get things out to the
> community faster.
>
> With future devices we may want to create a better path for
> integration into upstream drivers. But I also want users to get
> support for the devices as soon as those devices hit shelves in the
> market, maybe even before. So I would like to think of staging not
> only as a place for people to put drivers which a company has no
> resources to do the right job but also perhaps to _do_ the actual port
> work _with_ the community together.
This is already happening today, with at least two different network
drivers, so I have no objection to this at all.
> By doing so we get devices supported with whatever ugly piece of code
> makes the device run (as long as its open, upstreamble, etc) but we
> also can engage with the community on the actual engineering and
> future of the actual driver we do want to support in Linux.
>
> As time goes by hopefully staging will not be necessary as companies
> (like ours) will have an immediate well defined structure for their
> drivers to easily add support for further devices.
Sounds fine to me.
> If we should take this approach -- should we send patches for wireless
> staging to John, or Greg? It would still be "crap" so I don't expect
> John to accept to help maintain crap but what if its crap with a clear
> defined path to un-crap land?
I'll gladly take them, no objections from me.
thanks,
greg k-h
next prev parent reply other threads:[~2009-03-03 7:31 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-03 7:14 Staging, place holder for better company/community development model Luis R. Rodriguez
2009-03-03 7:30 ` Greg KH [this message]
2009-03-03 7:45 ` Luis R. Rodriguez
2009-03-03 15:56 ` Greg KH
2009-03-08 12:07 ` Johannes Berg
2009-03-08 22:33 ` Greg KH
2009-03-09 7:21 ` Johannes Berg
2009-03-09 19:41 ` Greg KH
2009-03-09 21:20 ` Johannes Berg
2009-03-11 5:00 ` Greg KH
2009-03-11 9:08 ` Johannes Berg
2009-03-11 16:02 ` Greg KH
2009-03-11 19:33 ` J.R. Mauro
2009-04-07 23:15 ` Greg KH
2009-03-08 23:02 ` Leon Woestenberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090303073045.GA4528@kroah.com \
--to=greg@kroah.com \
--cc=Senthilkumar.Balasubramanian@atheros.com \
--cc=Sujith.Manoharan@atheros.com \
--cc=hch@infradead.org \
--cc=j@w1.fi \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=m.sujith@gmail.com \
--cc=mcgrof@gmail.com \
--cc=vasanth@atheros.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.