On Mon, Feb 10, 2020 at 08:02:44PM +0000, Laurent Bercot wrote:
> 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.
Thanks. I just did not take inotify into consideration.
> 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.
Now I daydream again about the scsh-like mini-language I want :)
> It would be quite difficult to add a "udevadm settle" to mdevd. [...]
> 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.
Here I am more concerned about the coldplugging of disks, so that
loggers other than the catch-all can be started. I guess Alpine folks
would feel at home with similar requirements in `nlplug-findfs'...
> 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.
Frankly I was just attempting to find an excuse to introduce my idea of
"reverse" dependencies. The most important (and perhaps only) advantage
of the original way is that the devd has its own logger; but as we have
noticed, even the bloated udevd usually plays nice with the catch-all.
--
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Received on Tue Feb 11 2020 - 01:41:35 UTC