From: Evgeniy Polyakov <zbr@ioremap.net>
To: Stefan Strogin <sstrogin@cisco.com>,
"matthltc@us.ibm.com" <matthltc@us.ibm.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"xe-linux-external@cisco.com" <xe-linux-external@cisco.com>,
Victor Kamensky <kamensky@cisco.com>,
Taras Kondratiuk <takondra@cisco.com>,
Ruslan Bilovol <rbilovol@cisco.com>
Subject: Re: [RFC] connector: add group_exit_code and signal_flags fields to exit_proc_event
Date: Mon, 09 Apr 2018 02:49:47 +0300 [thread overview]
Message-ID: <8933031523231387@web29j.yandex.ru> (raw)
In-Reply-To: <307aa191-05b6-5227-19a0-13741c839fd1@cisco.com>
Hi everyone
Sorry for that late reply
01.03.2018, 21:58, "Stefan Strogin" <sstrogin@cisco.com>:
> So I was thinking to add these two fields to union event_data:
> task->signal->group_exit_code
> task->signal->flags
> This won't increase size of struct proc_event (because of comm_proc_event)
> and shouldn't break backward compatibility for the user-space. But it will
> add some useful information about what caused the process death.
> What do you think, is it an acceptable approach?
As I saw in other discussion, doesn't it break userspace API, or you are sure that no sizes has been increased?
You are using the same structure as used for plain signals and add group status there, how will userspace react,
if it was compiled with older headers? What if it uses zero-field alignment, i.e. allocating exactly the size of structure with byte precision?
next prev parent reply other threads:[~2018-04-08 23:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-01 18:58 [RFC] connector: add group_exit_code and signal_flags fields to exit_proc_event Stefan Strogin
2018-04-08 23:49 ` Evgeniy Polyakov [this message]
2018-04-10 16:01 ` Stefan Strogin
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=8933031523231387@web29j.yandex.ru \
--to=zbr@ioremap.net \
--cc=kamensky@cisco.com \
--cc=matthltc@us.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=rbilovol@cisco.com \
--cc=sstrogin@cisco.com \
--cc=takondra@cisco.com \
--cc=xe-linux-external@cisco.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 NNTP newsgroup(s).