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