[BUILDFIX PATCH] au0828: debug is a poor global identifier - Kernel

This is a discussion on [BUILDFIX PATCH] au0828: debug is a poor global identifier - Kernel ; Avoid link-time warnings with debug declared in x86/kernel/entry_32.S Signed-off-by: Harvey Harrison --- Otherwise you'll see link time warnings about multiple defintions of debug. (size 4 here, size 76 in entry_32.S) drivers/media/video/au0828/au0828-core.c | 14 +++++++------- drivers/media/video/au0828/au0828.h | 4 ++-- 2 files ...

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

Thread: [BUILDFIX PATCH] au0828: debug is a poor global identifier

  1. [BUILDFIX PATCH] au0828: debug is a poor global identifier

    Avoid link-time warnings with debug declared in x86/kernel/entry_32.S

    Signed-off-by: Harvey Harrison
    ---
    Otherwise you'll see link time warnings about multiple defintions of
    debug. (size 4 here, size 76 in entry_32.S)

    drivers/media/video/au0828/au0828-core.c | 14 +++++++-------
    drivers/media/video/au0828/au0828.h | 4 ++--
    2 files changed, 9 insertions(+), 9 deletions(-)

    diff --git a/drivers/media/video/au0828/au0828-core.c b/drivers/media/video/au0828/au0828-core.c
    index e65d564..9b7a4d7 100644
    --- a/drivers/media/video/au0828/au0828-core.c
    +++ b/drivers/media/video/au0828/au0828-core.c
    @@ -32,9 +32,9 @@
    * 4 = I2C related
    * 8 = Bridge related
    */
    -unsigned int debug;
    -module_param(debug, int, 0644);
    -MODULE_PARM_DESC(debug, "enable debug messages");
    +unsigned int au0828_debug;
    +module_param(au0828_debug, int, 0644);
    +MODULE_PARM_DESC(au0828_debug, "enable debug messages");

    unsigned int usb_debug;
    module_param(usb_debug, int, 0644);
    @@ -229,23 +229,23 @@ static int __init au0828_init(void)
    {
    int ret;

    - if (debug)
    + if (au0828_debug)
    printk(KERN_INFO "%s() Debugging is enabled\n", __func__);

    if (usb_debug) {
    printk(KERN_INFO "%s() USB Debugging is enabled\n", __func__);
    - debug |= 2;
    + au0828_debug |= 2;
    }

    if (i2c_debug) {
    printk(KERN_INFO "%s() I2C Debugging is enabled\n", __func__);
    - debug |= 4;
    + au0828_debug |= 4;
    }

    if (bridge_debug) {
    printk(KERN_INFO "%s() Bridge Debugging is enabled\n",
    __func__);
    - debug |= 8;
    + au0828_debug |= 8;
    }

    printk(KERN_INFO "au0828 driver loaded\n");
    diff --git a/drivers/media/video/au0828/au0828.h b/drivers/media/video/au0828/au0828.h
    index 0200b9f..8344c45 100644
    --- a/drivers/media/video/au0828/au0828.h
    +++ b/drivers/media/video/au0828/au0828.h
    @@ -96,7 +96,7 @@ struct au0828_buff {
    /* au0828-core.c */
    extern u32 au0828_read(struct au0828_dev *dev, u16 reg);
    extern u32 au0828_write(struct au0828_dev *dev, u16 reg, u32 val);
    -extern unsigned int debug;
    +extern unsigned int au0828_debug;
    extern unsigned int usb_debug;
    extern unsigned int bridge_debug;

    @@ -123,6 +123,6 @@ extern int au0828_dvb_register(struct au0828_dev *dev);
    extern void au0828_dvb_unregister(struct au0828_dev *dev);

    #define dprintk(level, fmt, arg...)\
    - do { if (debug & level)\
    + do { if (au0828_debug & level)\
    printk(KERN_DEBUG DRIVER_NAME "/0: " fmt, ## arg);\
    } while (0)
    --
    1.5.5.1.270.g89765



    --
    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. If you want me to quit I will quit

    > [BUILDFIX PATCH] au0828: debug is a poor global identifier

    Another issue for which I already sent a (slightly different) patch.

    Why not check the mailing list before duplicating work? [1]

    And if you e.g. discover next that our x86 userspace headers in
    2.6.25 (sic) are ****ed up guess who already sent a patch last
    weekend... [2]

    Why do other people get over 100 checkpatch fixes into the tree at once
    or Linus applies patches directly bypassing the maintainers (like the
    one you sent just before [3], which I've also already sent before [4])
    but my patches bitrot forever?

    And Linus didn't even bother to answer what the correct path for my
    patches is. [5]

    My current record is sending a patch 7 times (and still counting)
    without it getting applied anywhere. [6]

    And if anyone has doubts in the quality of my patches try to find
    commits of me in Linus' tree that introduced any bugs - you most
    likely won't find 3 buggy commits among my last 500 commits.

    Guys, this is neither a kindergarten nor the right place for corporate
    mobbing games. If you want to get rid of me simply say so and I'll
    immediately unsubscribe and stop bothering you with patches.

    Really annoyed
    Adrian

    [1] http://lkml.org/lkml/2008/4/25/376
    [2] http://lkml.org/lkml/2008/4/20/181
    [3] http://lkml.org/lkml/2008/4/25/511
    [4] http://lkml.org/lkml/2008/4/24/523
    [5] http://lkml.org/lkml/2008/4/2/369
    [6] http://lkml.org/lkml/2008/4/21/523
    http://lkml.org/lkml/2008/4/21/577

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    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: If you want me to quit I will quit

    Hi Adrian.

    > Why do other people get over 100 checkpatch fixes into the tree at once
    > or Linus applies patches directly bypassing the maintainers (like the
    > one you sent just before [3], which I've also already sent before [4])
    > but my patches bitrot forever?


    The patches you submit touches all parts of the kernel tree.
    And you do a good job in finding the relevant receivers.

    To me you are partly in the saem situation as Andrew in that
    you handle a great deal of patches touching a lot of different
    subsystems.
    We all know that the patch acceptance ratio differ a lot between
    the different maintainers and the way Andrew deals with this
    seems quite effective.
    After enough tries Andrew just submit the pacthes himself direct
    to Linus. But almost never without trying to get the relevant
    Maintainer to take it first.
    So in your position I would keep all patches in
    a place so they can be sucked into -next and regular spam
    the relevant amintainers with their patches.
    When the merge window opens then submit the rest to Linus
    with a noe that they have been sent to Maintainers without
    any feedback previously.

    This is not far away from what you do now and should not create
    that big frustrations (I hope).

    Sam
    --
    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: If you want me to quit I will quit

    On Sat, Apr 26, 2008 at 01:27:17PM +0200, Sam Ravnborg wrote:
    > Hi Adrian.


    Hi Sam,

    > > Why do other people get over 100 checkpatch fixes into the tree at once
    > > or Linus applies patches directly bypassing the maintainers (like the
    > > one you sent just before [3], which I've also already sent before [4])
    > > but my patches bitrot forever?

    >
    > The patches you submit touches all parts of the kernel tree.
    > And you do a good job in finding the relevant receivers.
    >
    > To me you are partly in the saem situation as Andrew in that
    > you handle a great deal of patches touching a lot of different
    > subsystems.
    >...


    Linus takes patches from people like Andrew, Al and Harvey directly,
    but he doesn't take the same patches directly from me.

    Whatever applies to these people doesn't help me.

    > So in your position I would keep all patches in
    > a place so they can be sucked into -next and regular spam
    > the relevant amintainers with their patches.
    > When the merge window opens then submit the rest to Linus
    > with a noe that they have been sent to Maintainers without
    > any feedback previously.
    >
    > This is not far away from what you do now and should not create
    > that big frustrations (I hope).


    You missed the "And Linus didn't even bother to answer what the correct
    path for my patches is."

    I'd have no problem creating a git tree for such stuff.

    But if Linus doesn't bother to tell me how he wants to get patches from
    me he most likely also won't bother to pull from my tree.


    And it wouldn't be usable for bugfixes that should get into 2.6.26.

    It might e.g. make sense to let maintainers handle fixes and let them
    decide whether they want a patch this way, but if my patch goes through
    the maintainer and later Linus applies the same patch by someone else
    directly it simply makes no sense that I spend my spare time on fixing
    bugs in the kernel.


    > Sam


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    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: If you want me to quit I will quit

    On Sat, 26 Apr 2008 14:00:44 +0300 Adrian Bunk wrote:

    > Why do other people get over 100 checkpatch fixes into the tree at once
    > or Linus applies patches directly bypassing the maintainers (like the
    > one you sent just before [3], which I've also already sent before [4])
    > but my patches bitrot forever?


    If I am not cc'ed on a patch and have to resort to plucking it off the
    mailing list it ends up being significantly more work and more error-prone
    for me to process it.

    I used to merge your patches but then you chose to stop ccing me on them so
    I stopped applying them. The increased hassle just isn't worth it for some
    random make-foo-static patch. I do try to keep an eye out for more
    significant changes but hey, stuff happens.

    You chose to disrupt the workflow and now you're here complaining and blaming
    others for the consequences of your own action.
    --
    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: If you want me to quit I will quit

    On Sat, Apr 26, 2008 at 07:51:32AM -0700, Andrew Morton wrote:
    > On Sat, 26 Apr 2008 14:00:44 +0300 Adrian Bunk wrote:
    >
    > > Why do other people get over 100 checkpatch fixes into the tree at once
    > > or Linus applies patches directly bypassing the maintainers (like the
    > > one you sent just before [3], which I've also already sent before [4])
    > > but my patches bitrot forever?

    >
    > If I am not cc'ed on a patch and have to resort to plucking it off the
    > mailing list it ends up being significantly more work and more error-prone
    > for me to process it.
    >
    > I used to merge your patches but then you chose to stop ccing me on them so
    > I stopped applying them. The increased hassle just isn't worth it for some
    > random make-foo-static patch. I do try to keep an eye out for more
    > significant changes but hey, stuff happens.
    >
    > You chose to disrupt the workflow and now you're here complaining and blaming
    > others for the consequences of your own action.



    Why didn't you tell me an explicit Cc is important for you?

    I'll resend my pending batch with a Cc to you.


    That only leaves the question why bugfixes are directly applied by Linux
    when they come from other people, but not when they come from me. Is
    there also a Cc required? But my patch for the x86 userspace headers
    ****up was Cc'ed to Linus (and I can't send it to -stable before it is
    in Linus' tree).

    Is the correct path for bug fixes to go through the maintainer or to go
    directly through Linus? And in the latter case, what was wrong with my
    patches?


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    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: If you want me to quit I will quit

    On Sat, 26 Apr 2008 18:23:41 +0300 Adrian Bunk wrote:

    > On Sat, Apr 26, 2008 at 07:51:32AM -0700, Andrew Morton wrote:
    > > On Sat, 26 Apr 2008 14:00:44 +0300 Adrian Bunk wrote:
    > >
    > > > Why do other people get over 100 checkpatch fixes into the tree at once
    > > > or Linus applies patches directly bypassing the maintainers (like the
    > > > one you sent just before [3], which I've also already sent before [4])
    > > > but my patches bitrot forever?

    > >
    > > If I am not cc'ed on a patch and have to resort to plucking it off the
    > > mailing list it ends up being significantly more work and more error-prone
    > > for me to process it.
    > >
    > > I used to merge your patches but then you chose to stop ccing me on them so
    > > I stopped applying them. The increased hassle just isn't worth it for some
    > > random make-foo-static patch. I do try to keep an eye out for more
    > > significant changes but hey, stuff happens.
    > >
    > > You chose to disrupt the workflow and now you're here complaining and blaming
    > > others for the consequences of your own action.

    >
    >
    > Why didn't you tell me an explicit Cc is important for you?


    Don't know, really. Something in me resiles from going and doing things
    which increase the patch volume, perhaps.

    > I'll resend my pending batch with a Cc to you.


    OK.

    Many of your make-static-foo-etc patches are in fact fixes against
    recently-merged changes, I think. It's better to get those fixes folded
    into the errant patch before things go into mainline: we get one correct
    commit in the permanent record rather than one dodgy commit followed by a
    later oh-let's-fix-that-up commit.

    So I'd encourage you to try to catch these things in -mm or linux-next and,
    if poss (and I know it's a bit of work), identify the offending commit.

    git-tree owners might need, umm, some encouragement here. It's much easier
    for them to slap the oh-let's-fix-that-up commit at the tail of their
    queue, which leaves us with the straggly commit record.
    --
    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: If you want me to quit I will quit


    On Saturday 26 April 2008, you wrote:
    > > [BUILDFIX PATCH] au0828: debug is a poor global identifier

    >
    > Another issue for which I already sent a (slightly different) patch.
    >
    > Why not check the mailing list before duplicating work? [1]
    >
    > And if you e.g. discover next that our x86 userspace headers in
    > 2.6.25 (sic) are ****ed up guess who already sent a patch last
    > weekend... [2]
    >
    > Why do other people get over 100 checkpatch fixes into the tree at once
    > or Linus applies patches directly bypassing the maintainers (like the
    > one you sent just before [3], which I've also already sent before [4])
    > but my patches bitrot forever?
    >
    > And Linus didn't even bother to answer what the correct path for my
    > patches is. [5]


    Linus just can't tell you directly to send him pull requests for patches
    touching kernel areas which are (or are supposed to be) maintained by other
    people but he isn't going to ignore properly justified git pull requests
    (see below).

    Also you may try this for your changes:

    * set -mm like tree containing all pending patches
    (+ ask for inclusion into -next tree and -mm tree)

    * send tree status updates to LKML (w/ some "marketing") regularly

    * send git pull requests to Linus with changes ACK-ed by relevant
    parties or lacking feedback (> 1 month timeout)

    > My current record is sending a patch 7 times (and still counting)
    > without it getting applied anywhere. [6]


    Please send a git pull request with v850 removal to Linus noting that:

    * the code has been broken for ages (since 2.6.19) and maintainer
    cannot be even reached, according to MAINTAINERS:

    UCLINUX FOR NEC V850
    P: Miles Bader

    * the patch was posted multiple times (first 3 months ago)
    and there were no complains

    * you've got an ACK from Greg Ungerer and you may add mine
    (FWIW, ACK-s from other arch maintainers would be more valuable),

    also back in February Ingo was positive about removing v850
    port and suggested adding info about it to

    Documentation/feature-removal-schedule.txt

    as a prerequisite for the removal (unfortunately it hasn't happened?)

    > And if anyone has doubts in the quality of my patches try to find
    > commits of me in Linus' tree that introduced any bugs - you most
    > likely won't find 3 buggy commits among my last 500 commits.


    Nobody questions quality of your patches - the problem is that they are
    spread all over the tree and are likely to conflict with other people's
    trees. Setting your own tree and putting it into -next tree seems like
    a best solution for this. It should also help in preventing duplicated
    work / patches getting lost.

    Thanks,
    Bart

    > Guys, this is neither a kindergarten nor the right place for corporate
    > mobbing games. If you want to get rid of me simply say so and I'll
    > immediately unsubscribe and stop bothering you with patches.
    >
    > Really annoyed
    > Adrian
    >
    > [1] http://lkml.org/lkml/2008/4/25/376
    > [2] http://lkml.org/lkml/2008/4/20/181
    > [3] http://lkml.org/lkml/2008/4/25/511
    > [4] http://lkml.org/lkml/2008/4/24/523
    > [5] http://lkml.org/lkml/2008/4/2/369
    > [6] http://lkml.org/lkml/2008/4/21/523
    > http://lkml.org/lkml/2008/4/21/577

    --
    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. Re: If you want me to quit I will quit



    On Sat, 26 Apr 2008, Adrian Bunk wrote:
    >
    > Linus takes patches from people like Andrew, Al and Harvey directly,
    > but he doesn't take the same patches directly from me.


    It's because I hate you.

    Oh, no, wait.

    It's because you didn't send the patch to me.

    Linus
    --
    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: If you want me to quit I will quit

    On Sat, Apr 26, 2008 at 09:51:48AM -0700, Linus Torvalds wrote:
    >
    >
    > On Sat, 26 Apr 2008, Adrian Bunk wrote:
    > >
    > > Linus takes patches from people like Andrew, Al and Harvey directly,
    > > but he doesn't take the same patches directly from me.

    >
    > It's because I hate you.
    >
    > Oh, no, wait.
    >
    > It's because you didn't send the patch to me.


    The patch for the x86 userspace header breakage last weekend was Cc'ed
    to you.

    > Linus


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    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: If you want me to quit I will quit

    On Sat, Apr 26, 2008 at 08:44:20AM -0700, Andrew Morton wrote:
    >...
    > git-tree owners might need, umm, some encouragement here. It's much easier
    > for them to slap the oh-let's-fix-that-up commit at the tail of their
    > queue, which leaves us with the straggly commit record.


    As far as I understand Linus on these matters people David Miller
    mustn't edit older commits in their trees once their tree got pushed
    out.

    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    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: If you want me to quit I will quit

    On Sat, Apr 26, 2008 at 02:00:44PM +0300, Adrian Bunk wrote:
    >...
    > And if you e.g. discover next that our x86 userspace headers in
    > 2.6.25 (sic) are ****ed up guess who already sent a patch last
    > weekend... [2]
    >...


    Sorry, I got that wrong.

    It was a past 2.6.25 breakage.

    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    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: If you want me to quit I will quit

    On Sat, 26 Apr 2008 20:16:04 +0300 Adrian Bunk wrote:

    > On Sat, Apr 26, 2008 at 08:44:20AM -0700, Andrew Morton wrote:
    > >...
    > > git-tree owners might need, umm, some encouragement here. It's much easier
    > > for them to slap the oh-let's-fix-that-up commit at the tail of their
    > > queue, which leaves us with the straggly commit record.

    >
    > As far as I understand Linus on these matters people David Miller
    > mustn't edit older commits in their trees once their tree got pushed
    > out.


    I expect that means "don't alter stuff after you've sent the pull request".
    That'd be fairly dumb.

    But during the two-month -rcX timeframe the patches in the git and quilt
    trees get altered, dropped, reordered regularly. Some of the git trees
    don't really exist, I believe - their owners assemble them from a
    quilt-based master tree for external sharing only.

    --
    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: If you want me to quit I will quit

    On Sat, Apr 26, 2008 at 10:20:24AM -0700, Andrew Morton wrote:
    > On Sat, 26 Apr 2008 20:16:04 +0300 Adrian Bunk wrote:
    >
    > > On Sat, Apr 26, 2008 at 08:44:20AM -0700, Andrew Morton wrote:
    > > >...
    > > > git-tree owners might need, umm, some encouragement here. It's much easier
    > > > for them to slap the oh-let's-fix-that-up commit at the tail of their
    > > > queue, which leaves us with the straggly commit record.

    > >
    > > As far as I understand Linus on these matters people David Miller
    > > mustn't edit older commits in their trees once their tree got pushed
    > > out.

    >
    > I expect that means "don't alter stuff after you've sent the pull request".
    > That'd be fairly dumb.
    >
    > But during the two-month -rcX timeframe the patches in the git and quilt
    > trees get altered, dropped, reordered regularly. Some of the git trees
    > don't really exist, I believe - their owners assemble them from a
    > quilt-based master tree for external sharing only.


    As far as I understand it, changes in Daves tree would cause problems
    for people like Jeff Garzik and John Linville who themselves base their
    work on Daves tree during the two-month -rcX timeframe.

    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    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: If you want me to quit I will quit



    On Sat, 26 Apr 2008, Adrian Bunk wrote:
    >
    > The patch for the x86 userspace header breakage last weekend was Cc'ed
    > to you.


    Yes, and I couldn't care less - it wasn't critical in any way (nobody
    should be using kernel headers directly in user space anyway, so the only
    people who could _possibly_ care were the people who build glibc releases
    etc).

    IOW, it wasn't a critical bug-fix that needed to be pushed out
    aggressively.

    Which means that I totally ignore a patch when I see that there are people
    who actually maintain that area (especially if I know they are responsible
    maintainers) that are also cc'd and that even reply to it.

    It so happens that that patch got merged into my tree today - unrelated to
    this discussion - and it came through all the normal channels (ie the x86
    maintainer tree).

    IOW, everything happened exactly the way it is SUPPOSED to happen.

    That said, it also obviously does happen that I lose patches for real.
    Maybe some of them even from you. But your complaints really aren't
    sensible in this case.

    Linus
    --
    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: If you want me to quit I will quit



    On Sat, 26 Apr 2008, Adrian Bunk wrote:
    > On Sat, Apr 26, 2008 at 08:44:20AM -0700, Andrew Morton wrote:
    > >...
    > > git-tree owners might need, umm, some encouragement here. It's much easier
    > > for them to slap the oh-let's-fix-that-up commit at the tail of their
    > > queue, which leaves us with the straggly commit record.

    >
    > As far as I understand Linus on these matters people David Miller
    > mustn't edit older commits in their trees once their tree got pushed
    > out.


    I wouldn't say "mustn't", because the _one_ thing I hate is totally rigid
    rules.

    What I do try to encourage is for people to think publicising their git
    trees as "version announcements". They're obviously _development_
    versions, but they're still real versions, and before you publicize them
    you should try to make sure that they make sense and are something you can
    stand behind.

    And once you've publicized them, you don't know who has that tree, so just
    from a sanity and debugging standpoint, you should try to avoid mucking
    with already-public versions. If you made a mistake, add a patch on top to
    fix it (and announce the new state), but generally try to not "hide" the
    fact that the state has changed.

    But it's not a hard rule. Sometimes simple cleanliness means that you can
    decide to go "oops, that was *really* wrong, let's just throw that away
    and do a whole new set of patches". But it should be something rare - not
    normal coding practice.

    Because if it becomes normal coding practice, now people cannot work with
    you sanely any more (ie some random person pulls your tree for testing,
    and then I pull it at some other time, and the tester reports a problem,
    but now the commits he is talking about don't actually even exist in my
    tree any more, and it's all really messy!).

    The x86 tree still does this. I absolutely detest it. Ingo claims that his
    model is better, and I'm pretty damn sure he's wrong. But until it starts
    causing bigger problems, I'll give him the benefit of the doubt.

    Linus
    --
    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: If you want me to quit I will quit



    On Sat, 26 Apr 2008, Adrian Bunk wrote:

    > On Sat, Apr 26, 2008 at 10:20:24AM -0700, Andrew Morton wrote:
    > >
    > > I expect that means "don't alter stuff after you've sent the pull request".
    > > That'd be fairly dumb.
    > >
    > > But during the two-month -rcX timeframe the patches in the git and quilt
    > > trees get altered, dropped, reordered regularly. Some of the git trees
    > > don't really exist, I believe - their owners assemble them from a
    > > quilt-based master tree for external sharing only.

    >
    > As far as I understand it, changes in Daves tree would cause problems
    > for people like Jeff Garzik and John Linville who themselves base their
    > work on Daves tree during the two-month -rcX timeframe.


    Yes. It really depends on how people use those trees.

    For trees that are *only* used for basically throw-away single-use testing
    (ie -mm and -next, both of which will always re-build the whole tree each
    time), changing a published tree doesn't matter at all, or matters very
    little.

    But once you get real people, rather than automation, that actually want
    to do development on top of a git tree, then rebuilding that tree is
    really really annoying for those users.

    So the networking tree, where you have other maintainers that are also git
    users, really shouldn't be rebuilt, because that messes with developers.

    Many other git trees are really more of a "private development trees that
    are exposed to -mm and -next to get some wider testing".

    Linus
    --
    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: If you want me to quit I will quit

    On Sat, Apr 26, 2008 at 10:21:33AM -0700, Linus Torvalds wrote:
    >
    >
    > On Sat, 26 Apr 2008, Adrian Bunk wrote:
    > >
    > > The patch for the x86 userspace header breakage last weekend was Cc'ed
    > > to you.

    >
    > Yes, and I couldn't care less - it wasn't critical in any way (nobody
    > should be using kernel headers directly in user space anyway, so the only
    > people who could _possibly_ care were the people who build glibc releases
    > etc).
    >
    > IOW, it wasn't a critical bug-fix that needed to be pushed out
    > aggressively.
    >
    > Which means that I totally ignore a patch when I see that there are people
    > who actually maintain that area (especially if I know they are responsible
    > maintainers) that are also cc'd and that even reply to it.
    >...


    I'm not yet getting your definition of a critical bug-fix.

    The patch of Harvey you already applied was a build fix in a well
    maintained area (Mauro would have sent you my patch today).

    Do you consider all patches that fix build errors as critical?
    If yes, only for x86 or for all architectures?

    > Linus


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    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: If you want me to quit I will quit

    >
    > Because if it becomes normal coding practice, now people cannot work with
    > you sanely any more (ie some random person pulls your tree for testing,
    > and then I pull it at some other time, and the tester reports a problem,
    > but now the commits he is talking about don't actually even exist in my
    > tree any more, and it's all really messy!).


    It also depends on whare you are located in the dependency tree.
    Being kbuidl maintainer I have very few people that actually
    pull me git tree (except from -mm and -next).
    So I rebase at will and have so far not got a single complaint
    from anyone pulling my tree.

    But people like Davem and Ingo sits much higher in the dependency chain
    and thus they have a very different set of users and thus a different
    set of problems to take into account.

    Sam
    --
    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: If you want me to quit I will quit



    On Sat, 26 Apr 2008, Adrian Bunk wrote:
    >
    > Do you consider all patches that fix build errors as critical?
    > If yes, only for x86 or for all architectures?


    I think that things that hold up people testing a development kernel is
    "important". Maybe not "critical", but certainly stuff I should fix asap,
    just so that people who might otherwise test a kernel (but aren't
    technical enough to fix even possibly trivial errors) won't get
    discouraged.

    And yes, x86(-64) is the one that matters a whole lot more for that kind
    of 'random tester' issue. If other architectures don't build in some
    random config, I don't consider that a huge deal, since anybody who builds
    a development kernel for (say) powerpc will also generally have the
    ability to fix whatever silly brown-paper-bug issue just as well as I
    could.

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