On Wed, Aug 24, 2022 at 1:13 AM Rob Landley <[email protected]> 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? TL;DR: no, i don't. although i don't directly work on that stuff (and dvander is more likely to have a canonical answer), i know a lot of people have _hoped_ to use it and looked at it over the years, but i don't think it's fit for purpose? the problem (ironically, given your complaint) is that it doesn't know _enough_ about the system. so it's racy and init has to run around after it fixing up the stuff (like selinux labels) that it _doesn't_ set. (iirc it didn't even do regular unix permissions right?) so if init's got to do _some_ of the work, init may as well do _all_ of the work so there's no window where you can see a "half-finished" node. 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 > [email protected] > http://lists.landley.net/listinfo.cgi/toybox-landley.net >
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
