[Toybox] [PATCH] losetup: Wait for ueventd to create loop device on Android

[Rob Landley]

Applied the patch, but WOW this is conceptually ugly...

On 8/23/22 10:57, Yi-yo Chiang via Toybox wrote:> Android doesn't use devtmpfs.

Huh, I thought Android was using it because you guys got blamed for shoehorning
userspace policy into the kernel back in 2013:

https://lwn.net/Articles/548477/#:~:text=devtmpfs

(The kernel having infrastructure to know that gid 44 is "video" and needing an
/etc/groups that matches is kinda creepy. Yet another thing Kay Sievers
advocated and Greg KH endorsed before Linus threw Kay out of kernel development
and he went off to do systemd full time...)

Do you think Android is likely to start using devtmpfs at some point in the
future? I didn't know there were any systems left doing hotplug without it.
There are some deeply embedded ones with a static /dev that never hotplug
anything, but those same systems often don't have /proc and /sys mounted either.
One of the few patches I still bother to send to lkml from time to time is
https://lkml.iu.edu/hypermail/linux/kernel/2201.2/00174.html because I'm using
it locally. I still have mdev on the toybox todo list because it's basically
hotplugd, but it moved WAY down the priority list and am not likely to keep the
original mknod behavior in a final version because devtmpfs happened.

> Instead device nodes under /dev are
> created by userspace daemon ueventd. There could be a noticeable delay
> between LOOP_CTL_GET_FREE issued and loop device created, so we need to
> wait until it is created and then continue.

With devtmpfs the device node is guaranteed to have been created before
returning to userspace, although you can still race with the hotplug notifier if
the creator and a daemon both try to respond to the device showing up. (Both the
the usermodehelper plumbing and the netlink socket will _dispatch_ before the
syscall returns, but the scheduler can do what it likes with different processes...)

And yes, I read through kernel code at one point to work this out. :P

> The timeout (5s) and time quantum (20ms) is picked randomly, it bares no
> special meaning but they worked fine empirically.

As I said, applied. All the ugly here is conceptual: there's no way to make
"this should not be happening" pretty.

Rob