Re: [PATCH] ptrace.2: Add details about usage of PTRACE_GET_SYSCALL_INFO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tried my best, hope I did it right!

Thanks for the assist!

And yes, it's Greek! Signing off with my github username most of the time.

Thanks again, here you go!

Βαλασιάδης Φώτιος

On 27/2/23 00:42, Alejandro Colomar wrote:
Hi Φώτης,

On 2/26/23 23:14, Φώτης Βαλασιάδης wrote:
Ahhhh hello everyone! Give me 20 minutes and I will make the changes as
requested!

By the way this patch is the very first patch I do through emails! I am
using git format-patch and git send-email, is it okay for me to be
opening a new thread for each change you request? Or should I send the
new patches in the same thread as responses?
It is good to keep them in the same thread,
which you can do with --in-reply-to= in git-format-patch(1).
In that case, I usually make it a reply of the previous patch
(not replies to it), or of the cover letter for patch sets.

That makes it easy for someone in the future to find stuff in
the mailing list.  For me right now it's not so much of a
problem, and I usually don't even check if someone made it a
reply or not; it's just a matter of how useful it will be in
the future (for insignificant patches I just send new threads).

Is there a universal standard or is it per project? Any guidance shall
be greatly appreciated!
I'd say there's no standards, but if you reply to the old thread
by default, it will be better than starting a new thread.  I can't
imagine why some project would want to avoid that.  It's more work
on your side though, so for small patches that just fix a typo,
you may not want to do it.

Thanks!
Cheers,

Alex

-- fvalasiad --
P.S.:  If you want to sign the patch with your name in non-Latin]
letters (is that Greek?), that's fine by me.  Whatever you prefer.  ;)

On 27/2/23 00:05, Alejandro Colomar wrote:
Hi Dmitry,

On 2/26/23 23:03, Dmitry V . Levin wrote:
On Sun, Feb 26, 2023 at 10:58:02PM +0100, Alejandro Colomar wrote:
[...]
+.B PTRACE_GET_SYSCALL_INFO
+is limited to type
+.B PTRACE_SYSCALL_INFO_NONE
+unless
+.B PTRACE_O_TRACESYSGOOD
+option is set before the corresponding ptrace stop has occurred.
You should say
.BR ptrace ()
right?
Or is unformatted ptrace common in this page?
Or just say "syscall stop".
Sure, that would work.  BTW, se prefer system call over syscall
(there's not much consistency regarding that, but let's try to achieve it).

Thanks,

Alex




[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux