Blackfin arch: add kdebug header file
PATCH 1/1 Blackfin arch: add kdebug header file
Hi folks,
This patch adds kdebug.h header file to blackfin architecture.
---
include/asm-blackfin/kdebug.h | 1 + 1 file changed, 1 insertion(+)
include/asm-blackfin/kdebug.h new file +1 -0
@@ -0,0 +1 @@ +#include <asm-generic/kdebug.h>
_
Thanks,
-Bryan Wu
I can see nothing wrong with your patches, but you should make the patch descriptions a little clearer:
Quoted 1 line · Bryan
Hi folks,
No need for this line, if it's there, Andrew just needs to remove it from the changelog.
Quoted 1 line
This patch adds
kdebug.hheader file to blackfin architecture.
This line is completely redundant, as it states the same information as the subject. You should give some background information here, like:
kdebug.h is needed for kprobes.
For trivial patches where the subject already tells the whole story (e.g. 'remove redundant declaration of foo'), just leave out the description entirely except for the Signed-off-by.
Arnd <><
you can even leave out the description
Quoted 3 lines · Arnd Bergmann
I can see nothing wrong with your patches, but you should make the patch descriptions a little clearer:
Thanks Arnd. I posted almost ten patches yesterday. Converting ten patches to preformatted Emails is terrible manually, you know.
How does a kernel guru to do this, send out dozens of patch emails a day? Is there any convenient tools to help this?
Quoted 12 lines · Bryan
Quoted 1 line
Hi folks,
No need for this line, if it's there, Andrew just needs to remove it from the changelog.
Quoted 1 line
This patch adds
kdebug.hheader file to blackfin architecture.This line is completely redundant, as it states the same information as the subject. You should give some background information here, like:
Quoted 8 lines
kdebug.his needed for kprobes.For trivial patches where the subject already tells the whole story (e.g. 'remove redundant declaration of foo'), just leave out the description entirely except for the Signed-off-by.
Arnd <><you can even leave out the description
I really appreciate your warmly advice.
Best Regards,
Bryan
Quoted 6 lines · Bryan
Thanks Arnd. I posted almost ten patches yesterday. Converting ten patches to preformatted Emails is terrible manually, you know.
How does a kernel guru to do this, send out dozens of patch emails a day? Is there any convenient tools to help this?
Most people either have patch-bombing scripts or just use git to take care of it. You should really consider the latter for getting updates merged in the future, now that most of the initial troubles are resolved.
Quoted 1 line · Paul Mundt
You should really consider the latter for getting updates merged in the future
we're planning for this, but the short term it isnt doable for us
Quoted 1 line
now that most of the initial troubles are resolved.
i would say initial troubles are resolved once we're in Linus' tree :) -mike
Quoted 6 lines · Mike Frysinger
Quoted 2 lines · Paul Mundt
You should really consider the latter for getting updates merged in the future
we're planning for this, but the short term it isnt doable for us
If you think mangling patches by hand is a more effective use of time, no one is stopping you -- some people even prefer that. On the other hand, if you're struggling with an effective methodology before things are merged, what reason is there to suspect that things will get better afterwards? Going by Bryan's post, it's clear that the current system isn't working for you at least.
Quoted 11 lines · Paul Mundt
Quoted 5 lines · Mike Frysinger
Quoted 2 lines · Paul Mundt
You should really consider the latter for getting updates merged in the future
we're planning for this, but the short term it isnt doable for us
If you think mangling patches by hand is a more effective use of time, no one is stopping you -- some people even prefer that. On the other hand, if you're struggling with an effective methodology before things are merged, what reason is there to suspect that things will get better afterwards?
we have a lot of infrastructure that the SCM is part of and at the moment, git is not a supported SCM
i'm not saying the current system is easy, just that we cant integrate git in the short term, so we'll continue spanking Bryan with the overhead :/
-mike
Quoted 13 lines · On Tue, 27 Mar 2007 01:17:06 -0400 Mike Frysinger wrote:
Quoted 11 lines · Paul Mundt
Quoted 5 lines · Mike Frysinger
Quoted 2 lines · Paul Mundt
You should really consider the latter for getting updates merged in the future
we're planning for this, but the short term it isnt doable for us
If you think mangling patches by hand is a more effective use of time, no one is stopping you -- some people even prefer that. On the other hand, if you're struggling with an effective methodology before things are merged, what reason is there to suspect that things will get better afterwards?
Quoted 6 lines
we have a lot of infrastructure that the SCM is part of and at the moment, git is not a supported SCM
i'm not saying the current system is easy, just that we cant integrate git in the short term, so we'll continue spanking Bryan with the overhead :/
In that case, Bryan may like to know that git, mercurial (IIRC), and quilt have patchbomb tools. Also GregKH has one somewhere (he can tell you where). And Paul Jacksone has one at
http://www.speakeasy.org/~pj99/sgi/sendpatchset
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
Quoted 18 lines · Randy Dunlap
Quoted 16 lines · On Tue, 27 Mar 2007 01:17:06 -0400 Mike Frysinger wrote:
Quoted 11 lines · Paul Mundt
Quoted 5 lines · Mike Frysinger
Quoted 2 lines · Paul Mundt
You should really consider the latter for getting updates merged in the future
we're planning for this, but the short term it isnt doable for us
If you think mangling patches by hand is a more effective use of time, no one is stopping you -- some people even prefer that. On the other hand, if you're struggling with an effective methodology before things are merged, what reason is there to suspect that things will get better afterwards?
we have a lot of infrastructure that the SCM is part of and at the moment, git is not a supported SCM
Quoted 9 lines
Quoted 3 lines
i'm not saying the current system is easy, just that we cant integrate git in the short term, so we'll continue spanking Bryan with the overhead :/
In that case, Bryan may like to know that git, mercurial (IIRC), and quilt have patchbomb tools. Also GregKH has one somewhere (he can tell you where). And Paul Jacksone has one at
http://www.speakeasy.org/~pj99/sgi/sendpatchset
Thanks for this guide line information. I will dig into it.
But in my experience, it is difficult to find right patch email receivers, even in the MAINTAINERS file. If there are 20 patch emails, we should find 20 email receivers at least and manually add them to the emails. This is terrible, right? Any idea?
Best Regards,
-Bryan
Quoted 7 lines · Bryan
Thanks for this guide line information. I will dig into it.
But in my experience, it is difficult to find right patch email receivers, even in the
MAINTAINERSfile. If there are 20 patch emails, we should find 20 email receivers at least and manually add them to the emails. This is terrible, right? Any idea?
The Cc: foo <bar@com> contained in the descrition is used to keep this info when you found it first time.
The patchbombing tools starts to support it.
Sam
Quoted 29 lines · Bryan
Quoted 18 lines · Randy Dunlap
Quoted 16 lines · On Tue, 27 Mar 2007 01:17:06 -0400 Mike Frysinger wrote:
Quoted 11 lines · Paul Mundt
Quoted 5 lines · Mike Frysinger
Quoted 2 lines · Paul Mundt
You should really consider the latter for getting updates merged in the future
we're planning for this, but the short term it isnt doable for us
If you think mangling patches by hand is a more effective use of time, no one is stopping you -- some people even prefer that. On the other hand, if you're struggling with an effective methodology before things are merged, what reason is there to suspect that things will get better afterwards?
we have a lot of infrastructure that the SCM is part of and at the moment, git is not a supported SCM
Quoted 9 lines
Quoted 3 lines
i'm not saying the current system is easy, just that we cant integrate git in the short term, so we'll continue spanking Bryan with the overhead :/
In that case, Bryan may like to know that git, mercurial (IIRC), and quilt have patchbomb tools. Also GregKH has one somewhere (he can tell you where). And Paul Jacksone has one at
http://www.speakeasy.org/~pj99/sgi/sendpatchset
Quoted 6 lines
Thanks for this guide line information. I will dig into it.
But in my experience, it is difficult to find right patch email receivers, even in the
MAINTAINERSfile. If there are 20 patch emails, we should find 20 email receivers at least and manually add them to the emails. This is terrible, right? Any idea?
Yes, well, we all have the honor of going thru that. There have been a few suggestions, but I haven't seen any that were Real Good IMO.
You'll learn (quickly) where most patches go (i.e., subsystems and their major maintainers/contributors). Just put those people into your email client address book and into the patch descriptions, like Sam said, so that the patchbomb tools can help you out with them.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
Quoted 38 lines · Randy Dunlap
Quoted 29 lines · Bryan
Quoted 18 lines · Randy Dunlap
Quoted 16 lines · On Tue, 27 Mar 2007 01:17:06 -0400 Mike Frysinger wrote:
Quoted 11 lines · Paul Mundt
Quoted 5 lines · Mike Frysinger
Quoted 2 lines · Paul Mundt
You should really consider the latter for getting updates merged in the future
we're planning for this, but the short term it isnt doable for us
If you think mangling patches by hand is a more effective use of time, no one is stopping you -- some people even prefer that. On the other hand, if you're struggling with an effective methodology before things are merged, what reason is there to suspect that things will get better afterwards?
we have a lot of infrastructure that the SCM is part of and at the moment, git is not a supported SCM
Quoted 9 lines
Quoted 3 lines
i'm not saying the current system is easy, just that we cant integrate git in the short term, so we'll continue spanking Bryan with the overhead :/
In that case, Bryan may like to know that git, mercurial (IIRC), and quilt have patchbomb tools. Also GregKH has one somewhere (he can tell you where). And Paul Jacksone has one at
http://www.speakeasy.org/~pj99/sgi/sendpatchsetQuoted 6 lines
Thanks for this guide line information. I will dig into it.
But in my experience, it is difficult to find right patch email receivers, even in the
MAINTAINERSfile. If there are 20 patch emails, we should find 20 email receivers at least and manually add them to the emails. This is terrible, right? Any idea?
Quoted 8 lines
Yes, well, we all have the honor of going thru that. There have been a few suggestions, but I haven't seen any that were Real Good IMO.
You'll learn (quickly) where most patches go (i.e., subsystems and their major maintainers/contributors). Just put those people into your email client address book and into the patch descriptions, like Sam said, so that the patchbomb tools can help you out with them.
Thanks a lot, I will try on my side. And one more question:
What is patchbomb tools, you mean git, quilt or other kernel patch management tool? I am using quilt and try to use git to manage patches. Is there a tool just named patchbomb?
Best Regards,
-Bryan
Quoted 7 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
In that case, Bryan may like to know that git, mercurial (IIRC), and quilt have patchbomb tools. Also GregKH has one somewhere (he can tell you where). And Paul Jacksone has one at
http://www.speakeasy.org/~pj99/sgi/sendpatchset
Quoted 5 lines
Thanks a lot, I will try on my side. And one more question:
What is patchbomb tools, you mean git, quilt or other kernel patch management tool? I am using quilt and try to use git to manage patches. Is there a tool just named patchbomb?
No, just the scripts listed above, including quilt & git (except that I can't find GregKH's script).
Signature · 3 lines
~Randy PS: I typo-ed Paul Jackson's name above. :(
Quoted 8 lines · Mike Frysinger
Quoted 7 lines · Paul Mundt
Quoted 5 lines · Mike Frysinger
Quoted 2 lines · Paul Mundt
You should really consider the latter for getting updates merged in the future
we're planning for this, but the short term it isnt doable for us
Quoted 8 lines
Quoted 4 lines
If you think mangling patches by hand is a more effective use of time, no one is stopping you -- some people even prefer that. On the other hand, if you're struggling with an effective methodology before things are merged, what reason is there to suspect that things will get better afterwards?
we have a lot of infrastructure that the SCM is part of and at the moment, git is not a supported SCM
I hope git will one of it. You know, with git kernel development will be much easier.
Quoted 3 lines
i'm not saying the current system is easy, just that we cant integrate git in the short term, so we'll continue spanking Bryan with the overhead :/
Cool, That's my duty.
-Bryan