[ANNOUNCE] linux-staging tree created - Kernel

This is a discussion on [ANNOUNCE] linux-staging tree created - Kernel ; 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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 30

Thread: [ANNOUNCE] linux-staging tree created

  1. [ANNOUNCE] linux-staging tree created

    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 testing the code.

    What this tree is not:
    - it is not a place to dump features that are being actively
    developed by a community of people (reiserfs4 for example.)
    - it is not a place to dump code and then run away, hoping that
    someone else will do the cleanup work for you. While there
    are developers available to do this kind of work, you need to
    get someone to agree to "babysit" the code.


    I'll follow up this message with a list of the current status of the
    individual patches and what is currently contained in the tree. I hope
    to release a status like this every week or so, depending on how the
    development goes.

    What I need from all of you:
    Kernel Janitors:
    Here is the perfect way to get involved. The code in this tree
    is in desparate need of cleanups and fixes that can be trivially
    found using 'sparse' and 'scripts/checkpatch.pl'. I'll gladly
    take these kinds of patches and of course, correctly credit you.

    Linux driver project developers:
    Same as above, here's a great place to start out helping with
    real code. If any of you wants to take any of these drivers
    over and become the primary contact point for them, just let me
    know.

    Linux-next developers:
    Stephen, I would really like this tree to be included in -next.
    Yes, I know it contains things that will not be included in the
    next release, but the inclusion and basic build testing that is
    provided by your tree is invaluable. You can place it at the
    end, and if there is even a whiff of a problem in any of the
    patches, you have my full permission to drop them on the floor
    and run away screaming (and let me know please, so I can fix it
    up.)

    Linux kernel developers:
    If there are any external patches floating around for drivers
    that need to be cleaned up and gotten into the kernel tree,
    please point them out to me and I'll be glad to add them to this
    tree and work to get them included. Right now we are pushing:
    - 192 files changed, 131073 insertions(+), 651 deletions(-)
    so what's a few more thousand lines of code

    Any questions? Comments?

    thanks,

    greg k-h
    --
    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/

  2. Re: [ANNOUNCE] linux-staging tree created

    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?

    - Ted

    --
    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/

  3. 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [ANNOUNCE] linux-staging tree created

    hi,

    On Tue, Jun 10, 2008 at 10:05 PM, Greg KH wrote:
    > 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.


    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
    --
    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/

  5. Re: [ANNOUNCE] linux-staging tree created

    Hi.

    Would you consider including TuxOnIce in it?

    I do still want to get it merged and would appreciate feedback.

    Regards,

    Nigel

    --
    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/

  6. Re: [ANNOUNCE] linux-staging tree created

    On Wed, Jun 11, 2008 at 03:07:30AM +0300, Felipe Balbi wrote:
    > hi,
    >
    > On Tue, Jun 10, 2008 at 10:05 PM, Greg KH wrote:
    > > 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.

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


    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
    --
    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/

  7. Re: [ANNOUNCE] linux-staging tree created

    On Wed, Jun 11, 2008 at 11:05:46AM +1000, Nigel Cunningham wrote:
    > Hi.
    >
    > Would you consider including TuxOnIce in it?
    >
    > I do still want to get it merged and would appreciate feedback.


    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
    --
    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/

  8. Re: [ANNOUNCE] linux-staging tree created

    Hi Greg.

    On Tue, 2008-06-10 at 20:29 -0700, Greg KH wrote:
    > On Wed, Jun 11, 2008 at 11:05:46AM +1000, Nigel Cunningham wrote:
    > > Hi.
    > >
    > > Would you consider including TuxOnIce in it?
    > >
    > > I do still want to get it merged and would appreciate feedback.

    >
    > Is the patch "stand-alone", only adding new code in discrete chunks like
    > a new driver or filesystem would?


    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
    filesystem.

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


    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

    --
    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/

  9. Template of what you're after? (Was [ANNOUNCE] linux-staging tree created)

    Hi again.

    On Tue, 2008-06-10 at 20:29 -0700, Greg KH wrote:
    > Is the patch "stand-alone", only adding new code in discrete chunks like
    > a new driver or filesystem would?


    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

    --
    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/

  10. Re: [ANNOUNCE] linux-staging tree created

    Greg,

    The OSD initiator (see
    http://git.open-osd.org/gitweb.cgi?p....git;a=summary)
    looks in principle like a great fit for linux-staging.

    What would be the mechanics of including it?

    Benny

    On Jun. 10, 2008, 22:05 +0300, Greg KH wrote:
    > 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 testing the code.
    >
    > What this tree is not:
    > - it is not a place to dump features that are being actively
    > developed by a community of people (reiserfs4 for example.)
    > - it is not a place to dump code and then run away, hoping that
    > someone else will do the cleanup work for you. While there
    > are developers available to do this kind of work, you need to
    > get someone to agree to "babysit" the code.
    >
    >
    > I'll follow up this message with a list of the current status of the
    > individual patches and what is currently contained in the tree. I hope
    > to release a status like this every week or so, depending on how the
    > development goes.
    >
    > What I need from all of you:
    > Kernel Janitors:
    > Here is the perfect way to get involved. The code in this tree
    > is in desparate need of cleanups and fixes that can be trivially
    > found using 'sparse' and 'scripts/checkpatch.pl'. I'll gladly
    > take these kinds of patches and of course, correctly credit you.
    >
    > Linux driver project developers:
    > Same as above, here's a great place to start out helping with
    > real code. If any of you wants to take any of these drivers
    > over and become the primary contact point for them, just let me
    > know.
    >
    > Linux-next developers:
    > Stephen, I would really like this tree to be included in -next.
    > Yes, I know it contains things that will not be included in the
    > next release, but the inclusion and basic build testing that is
    > provided by your tree is invaluable. You can place it at the
    > end, and if there is even a whiff of a problem in any of the
    > patches, you have my full permission to drop them on the floor
    > and run away screaming (and let me know please, so I can fix it
    > up.)
    >
    > Linux kernel developers:
    > If there are any external patches floating around for drivers
    > that need to be cleaned up and gotten into the kernel tree,
    > please point them out to me and I'll be glad to add them to this
    > tree and work to get them included. Right now we are pushing:
    > - 192 files changed, 131073 insertions(+), 651 deletions(-)
    > so what's a few more thousand lines of code
    >
    > Any questions? Comments?
    >
    > thanks,
    >
    > greg k-h
    > --
    > 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/


    --
    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/

  11. Re: [ANNOUNCE] linux-staging tree created

    Benny Halevy wrote:
    > Greg,
    >
    > The OSD initiator (see
    > http://git.open-osd.org/gitweb.cgi?p....git;a=summary)
    > looks in principle like a great fit for linux-staging.
    >


    The patches are not yet there, Benny. They are currently
    out-of-tree here:
    http://git.open-osd.org/gitweb.cgi?p....git;a=summary

    It will take me until end of next week to separate them into
    a consumable patchset. Which will also move them in-tree.

    > What would be the mechanics of including it?
    >


    I want to send them to linux-scsi-ml and also To: Greg KH
    Requesting to be included in "linux-staging tree". Is that
    sufficient?

    > Benny
    >


    Boaz

    > On Jun. 10, 2008, 22:05 +0300, Greg KH wrote:
    >> 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
    >>
    >>



    --
    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/

  12. Re: [ANNOUNCE] linux-staging tree created

    Hi,

    On Wed, Jun 11, 2008 at 12:50 PM, Boaz Harrosh wrote:

    > I want to send them to linux-scsi-ml and also To: Greg KH
    > Requesting to be included in "linux-staging tree". Is that
    > sufficient?


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

    Felipe Balbi
    felipebalbi@users.sourceforge.net
    --
    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/

  13. Re: [ANNOUNCE] linux-staging tree created

    On Tue, Jun 10, 2008 at 8:05 PM, Greg KH wrote:

    > 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 testing the code.
    >
    > What this tree is not:
    > - it is not a place to dump features that are being actively
    > developed by a community of people (reiserfs4 for example.)
    > - it is not a place to dump code and then run away, hoping that
    > someone else will do the cleanup work for you. While there
    > are developers available to do this kind of work, you need to
    > get someone to agree to "babysit" the code.


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

  14. Re: Template of what you're after? (Was [ANNOUNCE] linux-staging tree created)

    On Wed, Jun 11, 2008 at 02:03:45PM +1000, Nigel Cunningham wrote:
    > Hi again.
    >
    > On Tue, 2008-06-10 at 20:29 -0700, Greg KH wrote:
    > > Is the patch "stand-alone", only adding new code in discrete chunks like
    > > a new driver or filesystem would?

    >
    > 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.


    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
    --
    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/

  15. Re: [ANNOUNCE] linux-staging tree created

    On Wed, Jun 11, 2008 at 02:00:12PM +1000, Nigel Cunningham wrote:
    > Hi Greg.
    >
    > On Tue, 2008-06-10 at 20:29 -0700, Greg KH wrote:
    > > On Wed, Jun 11, 2008 at 11:05:46AM +1000, Nigel Cunningham wrote:
    > > > Hi.
    > > >
    > > > Would you consider including TuxOnIce in it?
    > > >
    > > > I do still want to get it merged and would appreciate feedback.

    > >
    > > Is the patch "stand-alone", only adding new code in discrete chunks like
    > > a new driver or filesystem would?

    >
    > 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
    > filesystem.
    >
    > > 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?

    >
    > 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).


    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
    --
    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/

  16. Re: [ANNOUNCE] linux-staging tree created

    On Wed, Jun 11, 2008 at 12:27:23PM +0300, Benny Halevy wrote:
    > Greg,
    >
    > The OSD initiator (see
    > http://git.open-osd.org/gitweb.cgi?p....git;a=summary)
    > looks in principle like a great fit for linux-staging.


    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
    keeping it from being included today?

    > What would be the mechanics of including it?


    Just send me a patch

    thanks,

    greg k-h
    --
    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/

  17. Re: [ANNOUNCE] linux-staging tree created

    On Wed, Jun 11, 2008 at 12:50:34PM +0300, Boaz Harrosh wrote:
    > Benny Halevy wrote:
    > > Greg,
    > >
    > > The OSD initiator (see
    > > http://git.open-osd.org/gitweb.cgi?p....git;a=summary)
    > > looks in principle like a great fit for linux-staging.
    > >

    >
    > The patches are not yet there, Benny. They are currently
    > out-of-tree here:
    > http://git.open-osd.org/gitweb.cgi?p....git;a=summary
    >
    > It will take me until end of next week to separate them into
    > a consumable patchset. Which will also move them in-tree.
    >
    > > What would be the mechanics of including it?
    > >

    >
    > I want to send them to linux-scsi-ml and also To: Greg KH
    > Requesting to be included in "linux-staging tree". Is that
    > sufficient?


    If they are to go into linux-scsi, why would you need/want them in the
    -staging tree as well?

    thanks,

    greg k-h
    --
    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/

  18. Re: [ANNOUNCE] linux-staging tree created

    On Wed, Jun 11, 2008 at 11:45:55AM +0100, Will Newton wrote:
    >
    > 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
    --
    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/

  19. Re: [ANNOUNCE] linux-staging tree created

    Greg KH wrote:
    > On Wed, Jun 11, 2008 at 12:50:34PM +0300, Boaz Harrosh wrote:
    >> Benny Halevy wrote:
    >>> Greg,
    >>>
    >>> The OSD initiator (see
    >>> http://git.open-osd.org/gitweb.cgi?p....git;a=summary)
    >>> looks in principle like a great fit for linux-staging.
    >>>

    >> The patches are not yet there, Benny. They are currently
    >> out-of-tree here:
    >> http://git.open-osd.org/gitweb.cgi?p....git;a=summary
    >>
    >> It will take me until end of next week to separate them into
    >> a consumable patchset. Which will also move them in-tree.
    >>
    >>> What would be the mechanics of including it?
    >>>

    >> I want to send them to linux-scsi-ml and also To: Greg KH
    >> Requesting to be included in "linux-staging tree". Is that
    >> sufficient?

    >
    > If they are to go into linux-scsi, why would you need/want them in the
    > -staging tree as well?
    >


    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
    all that there. It could help in exposure and testing of the code.

    > thanks,
    >
    > greg k-h


    Thanks
    Boaz
    --
    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/

  20. Re: [ANNOUNCE] linux-staging tree created

    On Wed, Jun 11, 2008 at 5:26 PM, Greg KH wrote:
    > On Wed, Jun 11, 2008 at 11:45:55AM +0100, Will Newton wrote:
    >>
    >> 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.


    Our tree is about 26000 lines of diff, including a few drivers.

    > Do you have an example of one that is currently not included in the main
    > kernel tree right now?


    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
    publically available toolchain.

    > thanks,
    >
    > greg k-h
    >

    --
    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/

+ Reply to Thread
Page 1 of 2 1 2 LastLast