[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <8933031523231387@web29j.yandex.ru>
Date: Mon, 09 Apr 2018 02:49:47 +0300
From: Evgeniy Polyakov <zbr@...emap.net>
To: Stefan Strogin <sstrogin@...co.com>,
"matthltc@...ibm.com" <matthltc@...ibm.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"xe-linux-external@...co.com" <xe-linux-external@...co.com>,
Victor Kamensky <kamensky@...co.com>,
Taras Kondratiuk <takondra@...co.com>,
Ruslan Bilovol <rbilovol@...co.com>
Subject: Re: [RFC] connector: add group_exit_code and signal_flags fields to exit_proc_event
Hi everyone
Sorry for that late reply
01.03.2018, 21:58, "Stefan Strogin" <sstrogin@...co.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?
Powered by blists - more mailing lists