On 8/24/22 05:04, Yi-yo Chiang wrote: > 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
Devtmpfs was introduced in 2009, so it wasn't an option in 2008. Plus it was initially controversial because they had previously done a REALLY STUPID implementation of the concept (I mean just spectacularly bad) that got ripped out: https://lwn.net/Articles/331818/ Devtmpfs got cleaned up into something simple and elegant which solves half the problem space of hotplug. It won't _eliminate_ the need for something like ueventd because when a device shows up you often need to do more than just make a /dev node for it. But for the "give me this dev node" case, when you make a syscall() or insmod and a device shows up, it eliminates the race waiting for asynchronous node creation: when the process gets control back, the node is there. > 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 ([email protected]) It's a bit like the old "is android going to use containers" question. Android predated container support by years so it had to do other things at first, and then had legacy dependencies on those other things. But eventually stuff like minijail started working their way into the stack using container plumbing. To clarify: I'm not pushing back against your patch because I think android should be using devtmpfs instead. I already merged your patch, and expect that to be the status quo for a while. I'm just going "over the next few years, this is a thing you might want to look into". But if you're not already working on it, I wouldn't expect to see it in the next android release or the one after that. Sigh: there's a bunch of stuff I consider obvious that apparently isn't. Back when I made initramfs use tmpfs in 2013 and didn't exactly advertise the benefits of that either. The embedded guys knew but most other people didn't notice. I should do some writeups on the advantages of various bits of plumbing... Eh, throw it on the todo heap. > OTOH I also wouldn't be surprised if some deeply modified Android distro > (wilderness) is already using devtmpfs. A quick google says devtmpfs is initialized in lineageos's boot messages, but who knows what that means? Hotplug has a whole mess of access handoffs to do securely, which I had to understand deeply back when I was doing mdev but that was a decade ago and I'm kind of stale on at this point. "Device insertion" isn't the same as creating a /dev node. New hardware showing up may trigger driver loading which may require an insmod and/or firmware loading. (You could put the firmware in initramfs and solve the license issues by having it be an externally loaded initramfs image, but no, they made a special magic MECHANISM for it. Ugh.) And some devices don't even HAVE /dev nodes (ethernet and wifi, thank you bill joy) and some have multiple nodes for the same device (ala partitioned hard drives), and of course some device nodes don't correspond to hardware at all (/dev/loop0)... This is why the original devfs was horrible even BEFORE it tried to use solaris names for all the devices. Also, devtmpfs doesn't usually create a world readable device, so a hotplug manager may adjust permissions and ownership. (That 2013 article I linked to was about letting drivers select permissions and uid:gid for the new node to show up as, which is a layering violation because THE KERNEL DOES NOT KNOW WHAT ANY UID OR GID OTHER THAN 0 OR 65534 MEAN, but that ship has apparently sailed...) I'm sure I wrote documentation about this, I'm like COMPULSIVE about doing that... Darn it, best I can find is an ancient half-assed version that trails off into notes to self: https://www.kernel.org/doc/local/hotplug-history.html Another failure mode of mine. Sorry. Anyway, the point of all this is devtmpfs solves a specific problem and clears up some nasty races, but it is by no means ALL of hotplug, and reenginering a pre-devtmpfs hotplug solution to NOT create its own /dev nodes requires a design rethink. (Which is why I haven't cycled back around to mdev.c in toybox, because it's not just "finish the code". I started mdev in 2005 and devtmpfs happened in 2009, I ALSO have to redesign bits of my old hotplug layer to not try to redo what devtmpfs already does better, and have too many other things competing for focus.) But with devtmpfs as part of this complete breakfast, race conditions like the one you just patched don't happen as much. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
