From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2972AC282CE for ; Wed, 24 Apr 2019 08:58:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E566721773 for ; Wed, 24 Apr 2019 08:58:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727747AbfDXI6f (ORCPT ); Wed, 24 Apr 2019 04:58:35 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:52585 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726451AbfDXI6f (ORCPT ); Wed, 24 Apr 2019 04:58:35 -0400 Received: from [192.168.1.115] ([95.114.95.254]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MwjO6-1gZo3b2LAg-00y9M4; Wed, 24 Apr 2019 10:56:53 +0200 Subject: Re: [PATCH RFC 1/2] Add polling support to pidfd To: Christian Brauner , Daniel Colascione Cc: Joel Fernandes , Jann Horn , Oleg Nesterov , Florian Weimer , kernel list , Andy Lutomirski , Steven Rostedt , Suren Baghdasaryan , Linus Torvalds , Alexey Dobriyan , Al Viro , Andrei Vagin , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , Kees Cook , linux-fsdevel , "open list:KERNEL SELFTEST FRAMEWORK" , Michal Hocko , Nadav Amit , Serge Hallyn , Shuah Khan , Stephen Rothwell , Taehee Yoo , Tejun Heo , Thomas Gleixner , kernel-team , Tycho Andersen References: <20190411175043.31207-1-joel@joelfernandes.org> <20190416120430.GA15437@redhat.com> <20190416192051.GA184889@google.com> <20190417130940.GC32622@redhat.com> <20190419190247.GB251571@google.com> <20190419191858.iwcvqm6fihbkaata@brauner.io> <20190419194902.GE251571@google.com> From: "Enrico Weigelt, metux IT consult" Organization: metux IT consult Message-ID: <1772079b-6e84-35e3-62b8-92034c29759d@metux.net> Date: Wed, 24 Apr 2019 10:56:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:hhphKdCu6l4QGadGKMP/R057kudvf56R8RLX18gA8jTh+tj2jbC hz1sT+N3+3qjNoGVg8+Tqhe3Hi8gS82K8R6/nBqbXH8XszWHvNWOe32yjChh4KxKdt60/SU +dkLbq6E+dO9jGgqDiJnjNvqshZRnnIqh2d8Alqsf4FbhyJlClslMmBpQuMgyg5vaGYD3Qa nuS13tQOUk436rbYn4JGg== X-UI-Out-Filterresults: notjunk:1;V03:K0:gJmd/FeBbGc=:V8JRDfOA3l+1I85jUGY9h5 lxGRdPw4oPoIeXwwXMTV/bdV1xWPtoR1EKYcjgsmRKFVhbpT3/tHwZh4e2ypYeD33k4JCLf/d Gv/F6Q/AQ8KwyFTc1J7D3QPSPloLkcCK2dcOkcEiGCXN4+cVn/aqgo5ElgA9u4wxyRLuiWEz3 QnG6eLN9STWXHuOAyFU6KtX0K3UpTmDSXnvnQPusA008DOolo8di9YwfGXIiJYfuG3WqfquQ9 U3SPZ7Bzy1K6Z/D9qlJ8uaG2Jk9dFbMlHlra1pMELReA9aIWJuUfOePukfM3dO9bksKULt1zF T9eWTH9muX3S1/swRTOzzLiEYhlEkHVJG1YMUyo1y3JvNmhFB5wcBbGACCBW/xB1m1GkusK1s cBgoU9DPKbsVxxvJnGchqkBY8PmiJ/hd1yJbX+ApEoM/OFh4mUDUpfizH2jjkR59u4bhl0c1b LI1FKqQloqjcRNRk7WwIc2wgrNB972Vo2OStNdDwC1t5gcwUF7pwYkBVVGk51ibiwtVd+kYu3 IAidf5OIyLpJbdXRm027Jj+gzu80sZ7ZMbIRIJy9RX1uwEM6OLDz378kq+bMXCsuuCCpW2Of/ HZBRscZYAzgDaBjqbK/p1l2Ci6E96oqHxOTJe0LGp88/ghwPMZOw7RzwIVob5+0Rf3N7rxy5f Ce/8EvuP8ZoWFoDrqHTQGTwxgHEqJGkWC/ugxfeZRkx+5UzyxgdEF7NV4IJgvxU55jEmo5Her CTio0z2ylYExzvZb6+ktqutSFEiVQ+Bx/22hDEUqRcFDAnigIKhZdQCfEFo= Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On 19.04.19 23:48, Christian Brauner wrote: > So is Android and we're not designing an interface for Android but for > all of userspace. > I hope this is clear. Service managers are quite important and systemd > is the largest one > and they can make good use of this feature. Maybe just talk about talking about service managers and not even mentioning systemd ;-) > That whole pargraph is about dismissing a range of valid use-cases based on > assumptions such as "way more common" and > even argues that service managers are special cases and therefore not > really worth considering. I would like to be more open to other use cases. ACK. Things like pidfd can make life for service managers a lot easier, and even allow whole new scenarios. For example, the monitoring part doesn't need to be the spawning process anymore. The spawner could send the pidfd to the monitor, eg. via unix socket. If we had plan9-like srv filesystem (something I've got on my todo list) we could even make the pidfd's available in the fs and so replace the old pidfiles (pidfile now would be really a process handle instead of just a scratchpad for writing down the pid). >> Joel indicated that he believes poll(2) >> shouldn't be supported on procfs pidfds. Is that your thinking as >> well? If that's the case, then we're in a state where non-parents > > Yes, it is. Why so ? IMHO, it would be much more useful, if another process can get the same process handle via procfs. This also would allow the scenario described above w/o srvfs: pidfiles could just be symlinks to the corresponding /proc files. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering info@metux.net -- +49-151-27565287