On Fri, Mar 15, 2019 at 07:24:28PM +0100, Christian Brauner wrote: [..] > > why do we want to add a new syscall (pidfd_wait) though? Why not just use > > standard poll/epoll interface on the proc fd like Daniel was suggesting. > > AFAIK, once the proc file is opened, the struct pid is essentially pinned > > even though the proc number may be reused. Then the caller can just poll. > > We can add a waitqueue to struct pid, and wake up any waiters on process > > death (A quick look shows task_struct can be mapped to its struct pid) and > > also possibly optimize it using Steve's TIF flag idea. No new syscall is > > needed then, let me know if I missed something? > > Huh, I thought that Daniel was against the poll/epoll solution? Hmm, going through earlier threads, I believe so now. Here was Daniel's reasoning about avoiding a notification about process death through proc directory fd: http://lkml.iu.edu/hypermail/linux/kernel/1811.0/00232.html May be a dedicated syscall for this would be cleaner after all. > I have no clear opinion on what is better at the moment since I have > been mostly concerned with getting pidfd_send_signal() into shape and > was reluctant to put more ideas/work into this if it gets shutdown. > Once we have pidfd_send_signal() the wait discussion makes sense. Ok. It looks like that is almost in though (fingers crossed :)). thanks, - Joel _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
