From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2852 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: "Laurent Bercot" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: mdevd / udevd issues, and the issue of "reverse" dependencies Date: Mon, 10 Feb 2020 20:02:44 +0000 Message-ID: References: <20200210171943.tzjltctjry2iqysx@caspervector> Reply-To: "Laurent Bercot" Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="17728"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: eM_Client/7.2.36908.0 To: "Casper Ti. Vector" , supervision@list.skarnet.org Original-X-From: supervision-return-2441-gcsg-supervision=m.gmane-mx.org@list.skarnet.org Mon Feb 10 21:02:46 2020 Return-path: Envelope-to: gcsg-supervision@m.gmane-mx.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by ciao.gmane.io with smtp (Exim 4.92) (envelope-from ) id 1j1FGX-0004Xu-NK for gcsg-supervision@m.gmane-mx.org; Mon, 10 Feb 2020 21:02:45 +0100 Original-Received: (qmail 21509 invoked by uid 89); 10 Feb 2020 20:03:11 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 21502 invoked from network); 10 Feb 2020 20:03:11 -0000 In-Reply-To: <20200210171943.tzjltctjry2iqysx@caspervector> X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedriedugdduudelucetufdoteggodftvfcurfhrohhfihhlvgemucfpfgfogfftkfevteeunffgpdfqfgfvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufffkjghfrhgfgggtgfesthhqredttderjeenucfhrhhomhepfdfnrghurhgvnhhtuceuvghrtghothdfuceoshhkrgdqshhuphgvrhhvihhsihhonhesshhkrghrnhgvthdrohhrgheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpohhuth Xref: news.gmane.io gmane.comp.sysutils.supervision.general:2852 Archived-At: >This has obvious benefits, at least for now. udevd does not have >a readiness notification mechanism (polling for the existence of >/run/udev/control surely does not count) There is no fundamental reason why it doesn't. inotify works on tmpfs; you don't need to poll for the existence of /run/udev/control, you can inotifywait for its appearance. > and s6's fd-based mechanism does not integrate well with the shell That is true, but I shamelessly chalk that up to the shell's limitations: the shell can't create anonymous pipes outside of a pipeline, and it can't make a pipeline without forking both the reader and the writer. It's a terrible tool when you need semi-serious plumbing work. > (Another issue, currently unsolved, >is that mdevd does not have a "udevadm settle" equivalent, so that in >theory we are not sure the basic devices are fully coldplugged when >`mdevd-coldplug' exits.) Funny you should mention that, it's the very problem I've been hitting last week :) It would be quite difficult to add a "udevadm settle" to mdevd. It would require a communication channel with the outside (a fifodir?), and heuristics to guesstimate when the coldplug starts and when it stops, which I'm not sure could be made reliable in all cases. To be fully reliable, the mechanism would need synchronization with the coldplugger, and at this point we're well on our way to duplicating the bloat of udevd. However, depending on the kind of device you're waiting for, it may be possible to avoid the race for that device. I needed to wait for a network interface to appear after the coldplug, so I wrote a tool that does just that: bcnm-waitif, in the bcnm package. (Documentation coming soon.) So at least network interfaces are covered now. >In the above, you have seen that I switched from `devd' depending on >`devices' to the converse. Suppose the problem of handling readiness in >the shell could be done in a "magically simple" way, I would personally >prefer the original way. I don't understand why you'd prefer the original way. The natural and normal way of proceeding is 1. start the daemon that processes the uevents, 2. trigger the initial hardware scan that produces a big batch of uevents. You don't need a temporary devd when you can just start the real one; if the interfaces around the existing devd implementations make it difficult to start properly, that's what should be fixed. -- Laurent