[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080610230522.GA25100@kroah.com>
Date: Tue, 10 Jun 2008 16:05:22 -0700
From: Greg KH <greg@...ah.com>
To: Theodore Tso <tytso@....edu>, linux-kernel@...r.kernel.org,
linux-next@...r.kernel.org, Stephen Rothwell <sfr@...b.auug.org.au>
Subject: Re: [ANNOUNCE] linux-staging tree created
On Tue, Jun 10, 2008 at 06:52:22PM -0400, Theodore Tso wrote:
> On Tue, Jun 10, 2008 at 12:05:40PM -0700, Greg KH wrote:
> > PURPOSE
> >
> > The linux-staging tree was created to hold drivers and filesystems and
> > other semi-major additions to the Linux kernel that are not ready to be
> > merged at this point in time. It is here for companies and authors to
> > get a wider range of testing, and to allow for other members of the
> > community to help with the development of these features for the
> > eventual inclusion into the main kernel tree.
> >
> > This tree will be included in the daily linux-next builds, and will get
> > testing by all users of that tree.
>
> Does this mean that the nature of linux-next is changing? I thought
> the whole point of linux-next was only to have what would be pushed to
> Linus in the near future, so we could check for patch compatibility
> issues. For that reason, for example, I don't push the unstable set
> of patches in the ext4 tree to linux-next, since they aren't ready for
> merging yet in their current form.
>
> But if linux-staging is going to be pushed to linux-next, doesn't that
> violate the ground rules of Linux-next? Or are we allowing in this
> case because these are filesystems and/or device drivers that don't
> exist at all in the mainline tree yet?
I'm asking for the rule to be bent for this tree, not that the whole
nature of linux-next is changing.
-staging is for only whole new drivers/filesystems, not changes/features
to existing code that is not yet ready for merging. The main reason
these drivers are not in mainline is usually:
- coding style issues
- sparse cleanups needed
- ioctl 32/64 cleanups
- locking review
- direct access to hardware through memory pointers (only works
on x86)
If you look at what I currently have, there's nothing earth-shattering
there, but there is stuff that users can use to get hardware to work
that currently is not supported on kernel.org kernels at all.
It would be nice if distros also pick it up if they want to support
these devices and give me some feedback. There are 2 big network
drivers in there that support a wide range of devices that some people
would like to see working :)
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists