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

[Yi-yo Chiang]

Digging through git history and I believe AOSP has been using "tmpfs as
/dev" plus "init and/or ueventd servicing uevents" since at least Android
1.0 (circa 2008,
https://android.googlesource.com/platform/system/core/+/4f6e8d7a00cbeda1e70cc15be9c4af1018bdad53
)
I'm not sure if the 2013 article is outdated, or are AOSP still on its way
to adopt devtmpfs. I'll bounce this question to David (dvander at google.com)

OTOH I also wouldn't be surprised if some deeply modified Android distro
(wilderness) is already using devtmpfs.

On Wed, Aug 24, 2022 at 4:13 PM Rob Landley <rob at landley.net> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220824/712ff522/attachment.htm>