DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=Hu5SJz2dmaeWfy9Ao7i9GEWl/GLOkVvVSJMbcm7/lOTzu62SmCdsHyPiGm1xAzTuaK
         VEXOQD0jdYJ+2/tI4Fueg0YSHmZ65dXeAZzPP9JK2F28tDLLbS6s9vBamcgQqC7u5tEp
         HZ5VUfrYqPiQzY57/8WVaUi9Q8yr1e8tAs8+s=
MIME-Version: 1.0
In-Reply-To: <20090903041429.GA29875@kroah.com>
References: <20090903041429.GA29875@kroah.com>
Date: Fri, 4 Sep 2009 20:25:41 +0200
Message-ID: <e7c6a05e0909041125h648874d5w56d23312d720270a@mail.gmail.com>
Subject: Re: Staging tree status for the .32 kernel merge
From: Belisko Marek <marek.belisko@gmail.com>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 11501
Lines: 233

Hi,

On Thu, Sep 3, 2009 at 6:14 AM, Greg KH<greg@kroah.com> wrote:
> Hi all,
>
> Here's a summary of the state of the drivers/staging/ tree, basically
> what will be coming in the 2.6.32 merge, and what the status of the
> different drivers are so far.
>
> First off, drivers/staging/ is NOT a dumping ground for dead code.  If
> no one steps up to maintain and work to get the code merged into the
> main portion of the kernel, the drivers will be removed.
>
> As proof of that, the EPL (Ethernet Power Link) driver will be removed
> in the .32 kernel, as no one is working on it, the upstream developers
> never respond to my emails, and no one seems to care about it.
>
> The pata_rdc driver is also going to be removed, as there is a "better"
> one being merged through the libata tree for this hardware.
>
> So, taking the drivers in chunks, here's some that have had active
> development on for the .32 release:
>        - rt* wireless drivers.  Bart has done amazing work merging all
>          of these together into something much better than they
>          originally were.  And even better, they still work!   Great
>          job Bart!
>
>        - rtl* wireless drivers.  Again, Bart has been doing great work
>          here.
>
>        - wlan-ng driver: a bit of work here, but this seems to be
>          dropping off, with the loss of a test platform for the driver.
>          Hopefully someone has a device around and can help out here.
>
>        - comedi drivers had only a bit of work done, lots more is
>          needed here, let's not loose the fact that this is getting
>          closer to a mergable shape.
>
>        - Android drivers have had a bit of work done, but upstream
>          seems to not care at all about what is going on here, as they
>          are working to forward port their code to the 2.6.29! kernel.
>          {sigh}.  If this keeps up, the drivers will be dropped in the
>          2.6.32 kernel release.
>          Note, Pavel has been adding some of the Dream hardware
>          drivers, which are separate from the core Android drivers.  I
>          have no objection to those, but they should work to get merged
>          to their "correct" places in the tree in another release or
>          so.
>
>        - w35und driver.  It's slowly being worked on.
>
>        - echo driver.  This one is now in good enough shape to merge
>          into the main kernel tree.  I'll send out review patches soon
>          for this.
>
>        - eth131x driver. Alan Cox is working on fixing up the issues in
>          this driver.  Hopefully it will get into mergable shape soon.
>
> New drivers that will show up in the .32 kernel release:
>        - vt66* wireless drivers.  These VIA drivers are being actively
>          worked on to get into a much better shape.  Nice job.
>
>        - new rt3090, and rtl8192e wireless drivers have been added and
>          worked on cleaning up issues involved in them.
>
>        - Microsoft Hyper-V drivers.  Over 200 patches make up the
>          massive cleanup effort needed to just get this code into a
>          semi-sane kernel coding style (someone owes me a bit bottle of
>          rum for that work!)  Unfortunately the Microsoft developers
>          seem to have disappeared, and no one is answering my emails.
>          If they do not show back up to claim this driver soon, it will
>          be removed in the 2.6.33 release.  So sad...
>
>        - quatech_usb2 driver.  I don't know if it quite works, but
>          someone is developing it, so I'm not complaining :)
>
>        - VME bus drivers.  Yeah!  They are progressing nicely.
>
>        - SEP and RAR drivers.  Alan Cox has been working on cleaning
>          these up a lot.
>
>        - IIO (Industrial I/O), these are new drivers that are being
>          actively worked on.
>
>        - pohmelfs and dst.  It seems that DST is dead, so I think I
>          will remove it in .33.  pohmelfs is under active development
>          outside of the tree, and hopefully patches start moving in
>          here to help out with keeping it up to date.
>
>        - cowloop.  Yes, another COW driver!  :)  Seriously, this does
>          things that DM can't do, so it might be useful.  The upstream
>          developer is interested in getting this merged properly, and
>          is working on cleaning it up.
>
> Drivers not being actively worked on:
>        - otus.  This is sitting here until a "real" wireless driver
>          will be merged through the wireless tree.  Hopefully that
>          happens soon.
>
>        - agnx wireless driver.  No one seems to care about it.  If no
>          one steps up soon, it will be removed in .33.
>
>        - altpciechdma.  Upstream developers seem to have disappeared.
>          Again, if no one steps up, it will be removed in .33
>
>        - asus_oled.  This only needs minor cleanups to get merged
>          properly into the main tree.  If someone wants an easy
>          project, this would be it.
I'll work on this driver. I'll send patches soon.
>
>        - at76_usb wireless driver.  Again, no one working on it, it
>          will be dropped in .33.
>
>        - b3dfg.  I really do not think anyone cares about this.  again,
>          will be dropped if this is true in .33.
>
>        - cpc-usb.  After the initial flurry of development, everyone
>          seems to have run away.  Was it the fact that I hadn't
>          showered in a few days?  Again, will be removed if no one
>          comes back.  And I am wearing deodorant now...
>
>        - frontier.  A nice driver, again, should not be hard to get
>          merged into the main tree, if someone wants an easy project...
>
>        - go7007.  Ugh.  Unless someone steps up now to take this over,
>          it's going to be removed in .33.  There is no hardware made
>          with this anymore, and no specs around that I know of, and the
>          code isn't the nicest in the world.
>
>        - heci.  A wonderful example of a company throwing code over the
>          wall, watching it get rejected, and then running away as fast
>          as possible, all the while yelling over their shoulder, "it's
>          required on all new systems, you will love it!"  We don't, it
>          sucks, either fix it up, or I am removing it.
>
>        - line6.  Another nice driver that should be simple to get
>          merged.  Please, if you are looking for something to do, this
>          is it.
>
>        - me4000 and meilhaus.  They work on the same hardware, and they
>          duplicate the existing COMEDI drivers.  Someone thinks that
>          custom userspace interfaces are fun and required.  Turns out
>          that being special and unique is not what to do here, use the
>          COMEDI drivers instead.  These will be removed.  Heck, I'll go
>          remove them for .32, there is no reason these should still be
>          around, except to watch the RT guys squirm as they try to
>          figure out the byzantine locking and build logic here (which
>          certainly does count for something, cheap entertainment is
>          always good.)
>
>        - mimio.  Another driver that should be simple to get merged.
>          Someone just step up to do this please, there are users of
>          this hardware out there.
>
>        - p9auth.  While it seemed like a good idea, I don't think that
>          anyone actually uses this.  It will be removed in .33 unless
>          someone comes forward.
>
>        - panel.  Another one that should be simple to merge.  Anyone?
>
>        - phison.  What?  I thought I asked for this to be merged a
>          while ago, sorry about that, no reason it should still be in
>          staging anymore, it's just so small it slipped through the
>          cracks...
>
>        - poch.  A long-suffering company is enduring the slowest
>          developers in the world here.  Hopefully the code will be
>          replaced with a UIO driver, but testing the userspace side
>          seems to be difficult and slow.  I have to give Redrapids
>          major credit for being patient here, they are being amazing.
>
>        - rspiusb.  A weird, very expensive camera, from a company that
>          does not want to release the specs, and wants custom userspace
>          interfaces.  The code hasn't built since the 2.6.20 days.
>          I'll go delete it now from .32, it doesn't deserve to live as
>          no one cares about it, least of all, the original authors of
>          the code :(
>
>        - slicoss and sxg.  These are being developed by a consulting
>          company for the main producer of the chips.  Yet they seem to
>          have disappeared half-way through the job.  Odd.  Hopefully
>          they come back soon.
>
>        - stlc45xx.  Another wireless driver that no one seems to care
>          about.  So sad.  I guess no one will miss it when it goes away
>          in .33.
>
>        - udlfb.  Video over USB, it doesn't get anymore whacked than
>          that.  This is still being developed but the developer doesn't
>          like to do incremental updates for some odd reason.  Hopefully
>          he pops up again with an update.  But for now, it is quite
>          workable for a number of developers.
>
>        - usbip.  USB over IP.  I guess if you ran video over IP to your
>          USB device, that would be more whacked than just video over
>          USB.  This did get one big update during the .32 development
>          cycle, hopefully the developer can come back again when they
>          get some free time to continue working on it.  Rumor has it
>          that some major distros are starting to rely on this code, so
>          it would be nice to get their help to get it working better...
>
> That should cover all of the 600+ patches in the staging tree for the
> .32 kernel merge, and the existing drivers/staging/ tree.  If I missed
> anything, please let me know.
>
> Any questions?
>
> thanks for making it this far,
>
> greg k-h
> _______________________________________________
> devel mailing list
> devel@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
>

Marek

-- 
as simple as primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
icq: 290551086
web: http://open-nandra.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/