Re: [boot-time]
Rob Landley <[email protected]> Sat, 11 Jan 2025 11:56:17 -0600
| Newsgroups | org.kernel.vger.linux-embedded |
|---|---|
| Message-ID | <[email protected]> |
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 Rob