<div dir="ltr"><div>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, <a href="https://android.googlesource.com/platform/system/core/+/4f6e8d7a00cbeda1e70cc15be9c4af1018bdad53" target="_blank">https://android.googlesource.com/platform/system/core/+/4f6e8d7a00cbeda1e70cc15be9c4af1018bdad53</a>)</div><div>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 (<a href="mailto:dvander@google.com" target="_blank">dvander@google.com</a>)</div><div><br></div><div>OTOH I also wouldn't be surprised if some deeply modified Android distro (wilderness) is already using devtmpfs.</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 24, 2022 at 4:13 PM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Applied the patch, but WOW this is conceptually ugly...<br>
<br>
On 8/23/22 10:57, Yi-yo Chiang via Toybox wrote:> Android doesn't use devtmpfs.<br>
<br>
Huh, I thought Android was using it because you guys got blamed for shoehorning<br>
userspace policy into the kernel back in 2013:<br>
<br>
<a href="https://lwn.net/Articles/548477/#:~:text=devtmpfs" rel="noreferrer" target="_blank">https://lwn.net/Articles/548477/#:~:text=devtmpfs</a><br>
<br>
(The kernel having infrastructure to know that gid 44 is "video" and needing an<br>
/etc/groups that matches is kinda creepy. Yet another thing Kay Sievers<br>
advocated and Greg KH endorsed before Linus threw Kay out of kernel development<br>
and he went off to do systemd full time...)<br>
<br>
Do you think Android is likely to start using devtmpfs at some point in the<br>
future? I didn't know there were any systems left doing hotplug without it.<br>
There are some deeply embedded ones with a static /dev that never hotplug<br>
anything, but those same systems often don't have /proc and /sys mounted either.<br>
One of the few patches I still bother to send to lkml from time to time is<br>
<a href="https://lkml.iu.edu/hypermail/linux/kernel/2201.2/00174.html" rel="noreferrer" target="_blank">https://lkml.iu.edu/hypermail/linux/kernel/2201.2/00174.html</a> because I'm using<br>
it locally. I still have mdev on the toybox todo list because it's basically<br>
hotplugd, but it moved WAY down the priority list and am not likely to keep the<br>
original mknod behavior in a final version because devtmpfs happened.<br>
<br>
> Instead device nodes under /dev are<br>
> created by userspace daemon ueventd. There could be a noticeable delay<br>
> between LOOP_CTL_GET_FREE issued and loop device created, so we need to<br>
> wait until it is created and then continue.<br>
<br>
With devtmpfs the device node is guaranteed to have been created before<br>
returning to userspace, although you can still race with the hotplug notifier if<br>
the creator and a daemon both try to respond to the device showing up. (Both the<br>
the usermodehelper plumbing and the netlink socket will _dispatch_ before the<br>
syscall returns, but the scheduler can do what it likes with different processes...)<br>
<br>
And yes, I read through kernel code at one point to work this out. :P<br>
<br>
> The timeout (5s) and time quantum (20ms) is picked randomly, it bares no<br>
> special meaning but they worked fine empirically.<br>
<br>
As I said, applied. All the ugly here is conceptual: there's no way to make<br>
"this should not be happening" pretty.<br>
<br>
Rob<br>
</blockquote></div><div><br></div></div>