> -----Original Message----- > From: Rob Landley <rob@xxxxxxxxxxx> > > On 1/11/25 02: 40, Marko Hoyer wrote: > > Am 11. 01. 25 um 00: 15 schrieb Rob Landley: >> On 1/10/25 16: 46, Marko Hoyer wrote: >>> > So I think it is worth talking a bit about udev and options to deal >>> with it but > On 1/11/25 02:40, Marko Hoyer wrote: > > > > Am 11.01.25 um 00:15 schrieb Rob Landley: > >> On 1/10/25 16:46, Marko Hoyer wrote: > >>> So I think it is worth talking a bit about udev and options to deal > >>> with it but adapting thinks a bit to todays world. I'm currently > >>> registering for the wiki, maybe I can setup an initial page at some > >>> time ... > >> > >> busybox mdev is a lot lighter weight, and can do pretty elaborate things. > >> > >> https://wiki.alpinelinux.org/wiki/Mdev > >> > >> https://github.com/fff7d1bc/mdev-like-a-boss > >> > >> The theory these days is you mount devtmpfs and then use mdev to add > >> scriptable behavior to device insertion/removal events via netlink > >> notifications. > >> > >> Rob > > > > Hey Rob, > > > > thx for the hint. Sounds good! > > > > How is the enumeration of cold plugged devices realized in mdev? Is it > > similar to udev triggering all devices in the complete device tree? > > mdev -s will scan /sys for current devices, it can be run as a hotplug > helper, and there's netlink support somewhere but I've never used it. > > https://busybox.net/downloads/BusyBox.html#mdev > > The hotplug helper doesn't require a persistent demon like netlink does > (or udev), at boot time you "mdev -s" to scan, then when you register a > hotplug helper the kernel spawns a new process with environment > variables whenever there's something new to do. The downside is if a lot > of events come in rapidly it can spawn a lot of processes in parallel > which makes sequencing difficult, which is why the netlink API exists as > an alternative, but that doesn't really happen in systems I've put > together, so... > > I wrote some introductory documentation about this back in 2007. It's a > bit stale, and never REALLY got finished, but... > > https://landley.net/kdocs/local/hotplug2.html > > That's the context within which sysfs happened. > > /dev and /sys serve different purposes: /dev shows the device drivers' > view of the system, full of devices that don't actually exist like > /dev/null, or five devices for one piece of hardware (partitions), > meanwhile a device that shows up but doesn't have a driver bound to it > yet won't be in /dev at all. This is half the reason the old > demon-managed "devfs" failed, it was CONCEPTUALLY wrong. (The other half > was it used crazy solaris names for everything so people looking for > /dev/hda1 couldn't find it and had to deal with some 9 character long > monstrosity instead. Plus Linux isn't a microkernel so expecting a > userspace demon to be necessary for /dev to _exist_ was just silly, and > also led to some problems booting the system because were does that > demon get its information from, eh?) > > sysfs is a hardware view of the system, where /sys/devices/pci0000:00 is > full of what bus probing found, and /sys/block/sda/dev contains "8:0" > (major and minor number) when a driver binds to something and goes > "mine", but something still had to mknod that. > > devtmpfs is a synthetic filesystem that just DOES that, when a new "dev" > node shows up under /sys/class or /sys/block it creates the apropriate > char or block device under dev with that major/minor and the same name > the directory uses (which is provided by the driver). > > Oh, "synthetic" filesystem is one of the four times of filesystem: block > backed, char/pipe backed, ram backed, and synthetic. I wrote > documentation about that a very long time ago... > > https://landley.net/toybox/doc/mount.html Hey Rob, This is a great review of /dev, /sys and the different ways that /dev gets populated. For a lot of embedded Linux devices, the only bus where new items can show up dynamically is USB. I've always thought the best solution (in terms of boot time) was to use static nodes in /dev during early boot (that is, just mknod the /dev nodes in the rootfs manually, and have them be present before the kernel even runs). No dynamic discovery or boot-time population of /dev needed. Then, sometime later, use either mdev or devtmpfs to accumulate (and remove?) other runtime-plugged devices. This can be done after the time-critical phase of booting. Does this overall approach work, or is there some in-kernel connections that may be missing if the dynamic tools are not used from startup? Thanks, -- Tim
