From: Levente Kurusa <levex@linux.com>
To: Dominique van den Broeck <domdevlin@free.fr>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] staging/rtl8192e: userspace ptr deref + incorrect declarations
Date: Mon, 5 May 2014 10:29:48 +0200 [thread overview]
Message-ID: <20140505082948.GA2581@linux.com> (raw)
In-Reply-To: <1399247989.2485.6.camel@wisdom>
[-- Attachment #1: Type: text/plain, Size: 3253 bytes --]
Hi,
On Mon, May 05, 2014 at 01:59:49AM +0200, Dominique van den Broeck wrote:
>
> Good evening,
>
> Forgive my mistakes, I sent only a few patches yet and I'm still learning.
> Nevertheless:
Not a problem at all, since that is what the challenge is for.
>
> > What is that period in the commit message? And the semicolon?
>
> Semicolons is what one use to ponctuate an enumerated list (at least
> in french). In fact, it was their primary use before computer era.
>
> Is there something wrong with it ? I check all my patches with
> checkpatch.pl --strict before sending them and it didn't seem to
> complain...
Oh, I see now! Well I guess it's better to have a commit message
that says WHY the change is good and WHAT did it change, not just
a list of what you did.
i.e. in this case you could also inline the sparse warning or at least
a part of it.
>
> > You should also be a bit more specific. Also, the Subject line is
> > very bad. Better go with something like this:
> >
> > staging: rtl8192e: fix userspace pointer dereference
>
> Right. I used the slash as a subpart of the tree. Didn't know what
> was the best for this situation.
That is good as well, I just prefer the latter one, but feel
free to use whichever you feel better. :-)
>
> > And when you resend a patchset, please resend the full patchset.
>
> I usually do but I've got an acceptation message for the first one
> (see below).
>
In that case, that's good.
> > This is totally unneccessary.
>
> Should at least have gone in the body below indeed.
>
> > When you cite a commit please don't include the full hash, that is
> > non informational. Better put the first 7 characters of the hash and
> > the first line of the commit message as well in parantheses, like so:
> >
> > 5169af2 ("Staging: rtl8192e: Fix declaration of symbols")
> > (I even have a command for this in vim :-) )
>
> I'm interested. I use vim too.
>
I have this:
----------%<-----------
function! GetGitCommit(commit)
exec ":.!git log --oneline --pretty=\"format:\\%h ('\\%s')\" ".a:commit." -1"
endfunction
---------->%-----------
> > Are you sure that 1/2 was applied to the staging tree?
> > It's unlikely that 1/2 is applied while 2/2 is left alone.
>
> As stated before, I received the common automatic mail from
> Greg KH regarding this one. So I'll now wait before I do a v3
> for this issue. If so, I'll resent the complete set if required.
No, if that was applied it's unneccessary to resend the full set.
>
> > Oh, I am unable to find commit b5c8d48 in Linus' or staging-next.
> > In which tree is it?
>
> It's linux-next. If I quote a commit, I should the tree as well,
> indeed. But since the v1 was performed partially for the Eudyptula
> Project and since it was a response to a modification request,
> I though it was implicit.
No, the tree's name is not needed. In fact, I should have checked it
in linux-next, but I only checked Linus', and staging-next thinking,
since you said it was applied, it was applied to staging-next. :-)
>
> > Could you please as well remove that empty line in the declarations?
>
> I'll do.
> Cheers.
Regards,
Levente Kurusa
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
prev parent reply other threads:[~2014-05-05 8:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-04 14:46 [PATCH v2 2/2] staging/rtl8192e: userspace ptr deref + incorrect declarations Dominique van den Broeck
2014-05-04 17:48 ` Levente Kurusa
2014-05-04 23:59 ` Dominique van den Broeck
2014-05-05 8:29 ` Levente Kurusa [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140505082948.GA2581@linux.com \
--to=levex@linux.com \
--cc=domdevlin@free.fr \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox