lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ