Message ID | 509B29F3.2040006@asianux.com |
---|---|
State | Changes Requested |
Delegated to: | David Miller |
Headers | show |
Hell David Miller: 1) Is this patch applied ? or need some discussion ? or suspended ? 2) If possible: A) can you tell me about our patch processing work flow " B) or some reference links (or document location) ? thanks. 于 2012年11月08日 11:41, Chen Gang 写道: > > when cp >= barg_buf + BARG_LEN-2, it only break internel loop (while) > but outside loop (for) still has effect, and "*cp++ = ' '" repeating > so need additional checking for it. > > > Signed-off-by: Chen Gang <gang.chen@asianux.com> > --- > arch/sparc/prom/bootstr_32.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/arch/sparc/prom/bootstr_32.c b/arch/sparc/prom/bootstr_32.c > index f5ec32e..25cda1c 100644 > --- a/arch/sparc/prom/bootstr_32.c > +++ b/arch/sparc/prom/bootstr_32.c > @@ -40,6 +40,10 @@ prom_getbootargs(void) > *cp++ = *arg++; > } > *cp++ = ' '; > + if(cp >= barg_buf + BARG_LEN-1){ > + /* We might issue a warning here. */ > + break; > + } > } > *cp = 0; > break; >
I'm backlogged and often without internet access, and therefore concentrating my limited time on kernel networking and much more important sparc changes such as bug fixes for problems people will actually hit. So you'll just need to be very patient. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
于 2012年11月09日 11:16, David Miller 写道: > > I'm backlogged and often without internet access, and therefore > concentrating my limited time on kernel networking and much more > important sparc changes such as bug fixes for problems people will > actually hit. > > So you'll just need to be very patient. > > ok, thanks, that is truly what I shall be. and I suggest: 1) can write a document for patch work flow and time waiting document 2) put it in a suitable location (can be easily found by new members). 3) I think this document is useful for the new members. thanks
Hi Chen, On Fri, Nov 9, 2012 at 2:15 PM, Chen Gang <gang.chen@asianux.com> wrote: > Hell David Miller: > > 1) Is this patch applied ? or need some discussion ? or suspended ? > > 2) If possible: > A) can you tell me about our patch processing work flow " > B) or some reference links (or document location) ? In regards to patches, you should assume that maintainers are: 1. grumpy 2. overworked 3. looking at your patch as you email them about it. (Note that only #2 is true, but it saves everyone time and aggravation if you assume the rest) 11 hours is not long enough for David to get to your patch, review it and apply it. I don't believe that there are any maintainers which would get to a patch that quickly. If David hadn't applied the patch within a few days of it being posted, then you might want to gently ask what's up. However, as Sam reviewed the patch and had some comments about it, it's unlikely that David will even look at it until you've addressed Sam's feedback. The best way to get a patch into the kernel is to follow the rules in Documentation/SubmittingPatches which you have, respond quickly to any feedback, be patient, be prepared to explain why you're doing what you're doing, and be prepared to change and resubmit your patch many times until everyone is happy with it. I'm sure that this is all written down in a document somewhere, but I can't recall what or where it is. Thanks,
Hi Julian Calaby: thank you for your reply, firstly. 1) I think what you reply are valuable (at least, for me, it is true). 2) I have read Documents/SubmittingPatches (which Eric Dumazet suggested) 3) I also think, it will be better, if put part contents of your reply into Documents/SubmittingPatches as completion. thanks. gchen. 于 2012年11月09日 13:06, Julian Calaby 写道: > Hi Chen, > > On Fri, Nov 9, 2012 at 2:15 PM, Chen Gang <gang.chen@asianux.com> wrote: >> Hell David Miller: >> >> 1) Is this patch applied ? or need some discussion ? or suspended ? >> >> 2) If possible: >> A) can you tell me about our patch processing work flow " >> B) or some reference links (or document location) ? > > In regards to patches, you should assume that maintainers are: > 1. grumpy > 2. overworked > 3. looking at your patch as you email them about it. > > (Note that only #2 is true, but it saves everyone time and aggravation > if you assume the rest) > > 11 hours is not long enough for David to get to your patch, review it > and apply it. I don't believe that there are any maintainers which > would get to a patch that quickly. > > If David hadn't applied the patch within a few days of it being > posted, then you might want to gently ask what's up. However, as Sam > reviewed the patch and had some comments about it, it's unlikely that > David will even look at it until you've addressed Sam's feedback. > > The best way to get a patch into the kernel is to follow the rules in > Documentation/SubmittingPatches which you have, respond quickly to any > feedback, be patient, be prepared to explain why you're doing what > you're doing, and be prepared to change and resubmit your patch many > times until everyone is happy with it. > > I'm sure that this is all written down in a document somewhere, but I > can't recall what or where it is. > > Thanks, >
Hello David Miller, Julian Calaby: 1) I am sorry for original mails to you: A) at 2012-11-09 00:33 Sam Ravnborg has already replied to me (need additional discussion) B) but I did not see it, it is my fault. C) at 2012-11-09 11:15 I sent mail to want to get reply, and you replied immediately. (the Time Location is at Beijing China) 2) sorry again, for bothering you, and also thank Sam Ravnborg's reply. 3) next time, I shall notice, and check my own mail carefully. Chen Gang -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/sparc/prom/bootstr_32.c b/arch/sparc/prom/bootstr_32.c index f5ec32e..25cda1c 100644 --- a/arch/sparc/prom/bootstr_32.c +++ b/arch/sparc/prom/bootstr_32.c @@ -40,6 +40,10 @@ prom_getbootargs(void) *cp++ = *arg++; } *cp++ = ' '; + if(cp >= barg_buf + BARG_LEN-1){ + /* We might issue a warning here. */ + break; + } } *cp = 0; break;
when cp >= barg_buf + BARG_LEN-2, it only break internel loop (while) but outside loop (for) still has effect, and "*cp++ = ' '" repeating so need additional checking for it. Signed-off-by: Chen Gang <gang.chen@asianux.com> --- arch/sparc/prom/bootstr_32.c | 4 ++++ 1 file changed, 4 insertions(+)