Re: [PATCH v2] signal: add procfd_signal() syscall

On December 7, 2018 7:56:44 AM GMT+13:00, Florian Weimer [off-list ref] wrote:

* Andy Lutomirski:

quoted

quoted

I suppose that's fine.  Or alternatively, when thread group support

is

quoted

quoted

added, introduce a flag that applications have to use to enable it,

so

quoted

quoted

that they can probe for support by checking support for the flag.

I wouldn't be opposed to a new system call like this either:

 int procfd_open (pid_t thread_group, pid_t thread_id, unsigned

flags);

quoted

quoted

But I think this is frowned upon on the kernel side.

I have no problem with it, except that I think it shouldn’t return an
fd that can be used for proc filesystem access.

Oh no, my intention was that it would just be used with  *_send_signal
and related functions.

Let's postpone that discussion a little.
I think we don't need a syscall to base this off of pids.
As I said I rather send my revived version of CLONE_NEWFD that would serve the same task.
The same way we could also just add a new open() flag that blocks fs access completely.
I just pitched that idea to Serge a few days back: O_NOCHDIR or similar.
That could even be part of Aleksa's path resolution patchset.

Thanks,
Florian