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 (dvan...@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 <r...@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 >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
