From: Greg KH <greg@kroah.com>
To: Theodore Tso <tytso@mit.edu>,
linux-kernel@vger.kernel.org, linux-next@vger.kernel.org,
Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [ANNOUNCE] linux-staging tree created
Date: Tue, 10 Jun 2008 16:05:22 -0700 [thread overview]
Message-ID: <20080610230522.GA25100@kroah.com> (raw)
In-Reply-To: <20080610225222.GG8397@mit.edu>
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
next prev parent reply other threads:[~2008-06-10 23:06 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-10 19:05 [ANNOUNCE] linux-staging tree created Greg KH
2008-06-10 19:06 ` linux-staging status for June 10, 2008 Greg KH
2008-06-10 22:52 ` [ANNOUNCE] linux-staging tree created Theodore Tso
2008-06-10 23:05 ` Greg KH [this message]
2008-06-11 0:07 ` Felipe Balbi
2008-06-11 3:28 ` Greg KH
2008-06-11 1:05 ` Nigel Cunningham
2008-06-11 3:29 ` Greg KH
2008-06-11 4:00 ` Nigel Cunningham
2008-06-11 16:24 ` Greg KH
2008-06-11 4:03 ` Template of what you're after? (Was [ANNOUNCE] linux-staging tree created) Nigel Cunningham
2008-06-11 16:23 ` Greg KH
2008-06-11 9:27 ` [ANNOUNCE] linux-staging tree created Benny Halevy
2008-06-11 9:50 ` Boaz Harrosh
2008-06-11 9:58 ` Felipe Balbi
2008-06-11 16:25 ` Greg KH
2008-06-11 17:43 ` Boaz Harrosh
2008-06-11 16:25 ` Greg KH
2008-06-11 10:45 ` Will Newton
2008-06-11 16:26 ` Greg KH
2008-06-12 11:37 ` Will Newton
2008-06-12 23:54 ` Greg KH
2008-06-13 14:14 ` Luis R. Rodriguez
2008-06-13 14:33 ` John W. Linville
2008-06-13 15:51 ` Luis R. Rodriguez
[not found] ` <20080613143328.GA16506-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
2008-06-14 0:28 ` Greg KH
[not found] ` <43e72e890806130714k535b041evaf750209ea492c47-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-06-14 0:27 ` Greg KH
2008-06-17 12:51 ` Pavel Machek
2008-07-02 23:11 ` Greg KH
2008-07-14 2:50 ` Jike Song
2008-07-14 2:56 ` Greg KH
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=20080610230522.GA25100@kroah.com \
--to=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=tytso@mit.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).