Oh great, not yet-another-kernel-tree, just what the world needs...
Yes, this is an announcement of a new kernel tree, linux-staging.  It is

a quilt series of patches that can be found at:

	git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
In a long and meandering thread with some of the other kernel developers

a week or so ago, it came up that there is no single place for companies

and developers to put their code for testing while it gets cleaned up

for submission into the kernel tree.  All of the different subsystems

have trees, but they generally only want code that is about to go into

this release, or the next one.  For stuff that is farther off, there is

no place to go.
So, here's the tree for it.  From the README:
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.
The rules of what can be included here is as follows:

	- the code must be released under a Linux kernel-compatible

	  license

	- the goal of the developers must be to merge this code into the

	  main kernel tree in the near future, but not for the next

	  kernel release.

	- the code must build properly on the x86 platform

	- this is not a tree for bugfixes or rewrites of existing kernel

	  code, this should be for new features, drivers, and

	  filesystems.

	- the patches included must detail exactly what is needed to be

	  completed in order for them to be included into the main

	  kernel tree.

	- there must be some email address associated with the patch

	  that can be used for bug reporting and questions about

	  cleanups and test...
[ message continues ]

Hi Greg,
Is there a separate mailing-list for staging?
--

Thanks and Regards,

Jike
--

Nope, lkml is fine for now, just be sure to cc: me so I notice it.
thanks,
greg k-h

--

Hmm, how do I tap into that developer pool? :-)
Kohjinsha wifi driver is in state where it was ported to mac80211, and

it still works with minimum features, but it needs dead code removal

and rewriting the rest. That code is really very ugly.
I can do the handholding; I can probably do the rewrite, too (its

10000LoC), but it will take time...
							Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

If the patch at least builds, send it to me for inclusion in -staging if

you want to get some exposure for it.
thanks,
greg k-h

--

This is great. To let this be useful for wireless we'll need

wireless-testing.git merged as we rely on it for the latest and
We have a few drivers which are not yet ready for

wireless-testing.git. Airgo is one.
Anyway, good stuff. Let me know what you think about letting this work

for wireless too.
  Luis

--

Hm, why?  Is it really needed for you to have this pulled in?  What is
If you have individual drivers, I'd be glad to take them into the tree

if you think it will help out.  Just send me a patch that can build

properly.
thanks,
greg k-h

--

I don't think directly pulling wireless-testing is a good idea of

-staging for process-related reasons.  However I think we can arrange

to send something for the new tree.  at76, airgo, and mrv8k are all

decent candidates.
Greg, how does the -staging tree get managed?  Is it periodically

rebuilt (like -next)?  Or would I need to send you pull requests?
John

--

John W. Linville

linville@tuxdriver.com

--

Just send me patches, it's a quilt tree.
thanks,
greg k-h

--

On Fri, Jun 13, 2008 at 7:33 AM, John W. Linville
Its just quit patches.
  Luis

--

Would the linux-staging tree be an appropriate place to merge a new

architecture? Or would that be too large a change and should go via

its own tree?

--

That is probably too big to go into -staging and should deserve its own

tree based on the size of patches that have gone into creating a new

architecture in the past.
Do you have an example of one that is currently not included in the main

kernel tree right now?
thanks,
greg k-h

--

I have a tree that is currently about half way to public consumption,

although I don't think there's any point pushing it until we have a

--

Yeah, that would help as well :)
thanks,
greg k-h

--

Greg,
The OSD initiator (see

http://git.open-osd.org/gitweb.cgi?p=open-osd.git;a=summary)

looks in principle like a great fit for linux-staging.
What would be the mechanics of including it?
Benny
--

Why isn't that just going directly into the linux-scsi tree when ready?
It doesn't look like it has coding style issues, does it?  What is
Just send me a patch :)
thanks,
greg k-h

--

The patches are not yet there, Benny. They are currently

out-of-tree here:

http://git.open-osd.org/gitweb.cgi?p=osd-lib.git;a=summary
It will take me until end of next week to separate them into
I want to send them to linux-scsi-ml and also To: Greg KH

Requesting to be included in "linux-staging tree". Is that
<snip>
--

If they are to go into linux-scsi, why would you need/want them in the

-staging tree as well?
thanks,
greg k-h

--

We're jumping the guns here a bit, but ...
The code is pretty stable and robust as far as the protocol and performance

is concerned, surly once I in-tree them, divide them into patches, prettify

comments, add file-headers, and checkpatch them.
But the bigger implications are not yet clear, and will need advise from

the list, which could take time. Mainly in regard to upper ULD and tests.

Currently there are 4 users for this code:

- pNFS-over-objects layout driver

- pNFS-over-objects Simple Server implementation (spNFS)

- OSDVFS - Virtual psuedo file system to access and debug OSD luns from user mode.

          (This is not the OSDFS from IBM which is a general FS over objects,

           but a direct representation of the OSD Lun to user mode)

- Testing
The first 3 are their own ULD and do not need a proper SCSI-ULD. With some

changes to sg.c they can manage with what we have now. The later is just

for debugging.
On the other hand a true OSD-ULD that exports /dev/osdx char and/or block

devices, has merits and future directions of it's own. And will eliminate

the need for changes in sg.c
So the mechanics are pretty much there but the direction is not clear, which

will govern the folders/exports/dependencies. But I'm not sure -staging tree

will help in any of that. I do have my git.open-osd.org exports and can manage
Thanks

Boaz

--

Hi,
just don't forget to add copyright notes in all files :-)--

Best Regards,
Felipe Balbi

felipebalbi@users.sourceforge.net

--

Hi.
Would you consider including TuxOnIce in it?
I do still want to get it merged and would appreciate feedback.
Regards,
Nigel
--

Is the patch "stand-alone", only adding new code in discrete chunks like

a new driver or filesystem would?
If not, I don't think it is relevant.  Odds are you want to be your own

series of patches, like we discussed years ago, right?
thanks,
greg k-h

--

Hi again.
Just another thought - I should have said that I don't really know what

patches to add a new driver or filesystem look like. I can only imagine

a filesystem going in all-in-one-patch, so I'd probably appreciate an

example/template to work off, as might others.
Regards,
Nigel
--

If you look in the -staging tree, there are 17 "template/example"

patches in there to go off of :)
Basically, one patch per feature.  It sounds like the tuxonice is much

too big for this kind of thing.
Just respin your patches and post them to lkml for review.  You should

be able to set up your own tree for inclusion in linux-next if they are

ready to go in.
thanks,
greg k-h

--

Hi Greg.
The patch I distribute now does have a few parts to it that could be

separated into distinct patches (cryptoapi LZF support, fuse freezer

support), but the bulk of it is TuxOnIce itself, which just adds new

files and inserts the hooks necessary to share the lowlevel code with

[u]swsusp. I think, therefore, it would akin to adding a new driver or
I don't think I do want to have my own series of patches, because

TuxOnIce doesn't remove or rework swsusp or uswsusp, but sits along side

them. I'm not trying to mutate swsusp into TuxOnIce, because that would

require a complete rework of swsusp from the ground up (TuxOnIce does

everything but the atomic copy/restore and associated prep/cleanup

differently).
Regards,
Nigel
--

Like always, you need to divide your changes up into logical chunks in

order to get them approved and reviewed.  For such a core functionality

like suspend, this is extra important.
I do not think that -staging is proper for this kind of feature at this

point in time.
thanks,
greg k-h

--

hi,
That's great. I started working on the test and measurement class

driver. Do you want me to send preliminary patches or just the final

one ?
--

Best Regards,
Felipe Balbi

felipebalbi@users.sourceforge.net

--

I'll take whatever you have, prelim patches is nice if you are at a

stopping point and want to make sure I get them applied :)
thanks,
greg k-h

--

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?
						- Ted
--

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

--

Here is a list of the current patches in the linux-staging tree, and

their current status.
 - 17 patches

 - 192 files changed, 131073 insertions(+), 651 deletions(-)
---------

Patch: aectc: add the aectc driver

Contact: Brandon Philips <brandon@ifup.org>
Status:

  Being reworked to use the UIO interface instead of char driver

  Part of the linuxdriverproject.org development effort.
---------

Patch: DVB: add firesat driver

Contact: Manu Abraham <manu@linuxtv.org> and Greg KH <greg@kroah.com>
Status:

  Currently waiting for more DVB tuner development to finish off the

  remaining features.  Will be submitted to the DVB developers for

  inclusion in the kernel tree soon, as waiting for that effort might be

  a while.

  Part of the linuxdriverproject.org development effort.
---------

Patch: Framebuffer: add the VIA framebuffer driver

Contact: Benjamin Pan <BenjaminPan@viatech.com> and Greg Kroah-Hartman <greg@kroah.com>
Status:

  many TODOs still left to finish (see patch for details)

  Part of the linuxdriverproject.org development effort.
---------

Patch: Input: add appleir driver

Contact: Greg Kroah-Hartman <greg@kroah.com>
Status:

  looks like this is not needed at all, but still need to determine the

  proper HID quirk.

  Part of the linuxdriverproject.org development effort.
---------

Patch: me4000: add pci data collection driver

Patch: me4000 firmware file

Contact: Greg Kroah-Hartman <greg@kroah.com>
Status:

  many TODOs still left to finish (see patch for details)

  Part of the linuxdriverproject.org development effort.
---------

Patch: NET: add Alacritech slicoss driver

Contact: Greg Kroah-Hartman <greg@kroah.com>
Status:

  many TODOs still left to finish (see patch for details)

  Part of the linuxdriverproject.org development effort.
---------

Patch: NET: add et131x driver

Contact: Greg Kroah-Hartman <greg@kroah.com>
Status:

  many TODOs still left to finish (see patch for det...
[ message continues ]