public inbox for cygwin-patches@cygwin.com
 help / color / mirror / Atom feed
From: Brian Inglis <Brian.Inglis@Shaw.ca>
To: cygwin-patches@cygwin.com
Subject: Re: [PATCH v4 0/3] use wincap in format_proc_cpuinfo for user_shstk
Date: Tue, 20 Jun 2023 22:50:58 -0600	[thread overview]
Message-ID: <6783769f-fb78-9ae7-bda9-ce64b79125d3@Shaw.ca> (raw)
In-Reply-To: <ZJFh2Cy9PnCqNoYU@calimero.vinschen.de>

On 2023-06-20 02:22, Corinna Vinschen wrote:
> On Jun 19 12:15, Brian Inglis wrote:
>> In test for for AMD/Intel Control flow Enforcement Technology user mode
>> shadow stack support replace Windows version tests with test of wincap
>> member addition has_user_shstk with Windows version dependent value
>>
>> Fixes: 41fdb869f998 fhandler/proc.cc(format_proc_cpuinfo): Add Linux 6.3 cpuinfo
>> Signed-off-by: Brian Inglis <Brian.Inglis@Shaw.ca>
>>
>> Brian Inglis (3):
>>    wincap.h: add wincap member has_user_shstk
>>    wincap.cc: set wincap member has_user_shstk true for 2004+
>>    fhandler/proc.cc: use wincap.has_user_shstk
>>
>>   winsup/cygwin/fhandler/proc.cc        |  8 ++++----
>>   winsup/cygwin/local_includes/wincap.h |  2 ++
>>   winsup/cygwin/wincap.cc               | 10 ++++++++++
>>   3 files changed, 16 insertions(+), 4 deletions(-)
> 
> Never mind, I fixed the remaining problems.  Thanks for the patch,
> I pushed it with slight modifications to the commit messages.
> 
> I'm a bit puzzled if my original mail
> https://cygwin.com/pipermail/cygwin-patches/2023q2/012280.html
> was really that unclear.  Reiterating for the records:
> 
> - Commit messages should really try to explain why the patch is made and
>    what it's good for. In case of fixing a bug, the bug should be explained
>    and, ideally, explain why the patch is the better solution.
> 
> - If a patch fixes an older bug, it should say so and point out the
>    commit which introduced the bug using the Fixes: tag.  The format
>    is
>    
>      Fixes: <12-digit-SHA1> ("<commit headline>")
> 
>    The parens and quoting chars are part of the format.
> 
> - Every patch should contain a Signed-off-by: to indicate that
>    you did the patch by yourself.  That's easily automated by
>    using `git commit -s'.
> 
> - Other Tags like "Reported-by:" or "Tested-by:" are nice to have,
>    but not essential.

>> - For obvious reasons, the message text in your cover message won't make
>>   it into the git repo.  However, the commit messages in git should
>>   reflect why the change was made, so a future interested reader has
>>   a chance to understand why a change was made.

Not obvious to me unfortunately!

>> - As I already mentioned a couple of times on this list (but not
>>   lately), it would be great if you could always add a "Signed-off-by:"
>>   line.

I added that to my config.

>> - Also, given this patch fixes an earlier patch, it should contain
>>   a line
>> 
>>     Fixes: <12-digit-SHA1> ("commit headline")

ASSUME NOTHING (as we used to write in masm) about me, git, background info, or 
conventions: man page or link refs please?

I personally used CVS then Hg, and needed BK for another project.

I only use git seriously for this project, as most businesses supported at best 
CVS, most projects relied on backups of network shares, and saw little value in 
source control, even in software cos; others were anal about it, requiring 
diffs, but did not trust developers (maybe just contractors) with access to 
their secure vaults!
[It made for interesting chats, some after I was gone, when their test builds 
were still showing bugs I had fixed, tested, and submitted source changes for 
weeks earlier!]

After trying to earlier track down useful docs I just managed to find:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst

which presumably is the background I need?

Some stuff is also mentioned in:

https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/SubmittingPatches

which may have a more explanatory and practical focus.

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer     but when there is no more to cut
                                 -- Antoine de Saint-Exupéry

  reply	other threads:[~2023-06-21  4:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-19 18:15 Brian Inglis
2023-06-19 18:15 ` [PATCH v4 1/3] wincap.h: add wincap member has_user_shstk Brian Inglis
2023-06-19 18:15 ` [PATCH v4 2/3] wincap.cc: set wincap member has_user_shstk true for 2004+ Brian Inglis
2023-06-19 18:15 ` [PATCH v4 3/3] fhandler/proc.cc: use wincap.has_user_shstk Brian Inglis
2023-06-20  8:22 ` [PATCH v4 0/3] use wincap in format_proc_cpuinfo for user_shstk Corinna Vinschen
2023-06-21  4:50   ` Brian Inglis [this message]
2023-06-21  8:22     ` Corinna Vinschen
2023-06-21 15:04       ` Brian Inglis

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=6783769f-fb78-9ae7-bda9-ce64b79125d3@Shaw.ca \
    --to=brian.inglis@shaw.ca \
    --cc=cygwin-patches@cygwin.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).