Chromium, radeon, and Thunar are all dependent on systemd...
They arent't, they depend on udev. It's just that Arch packages systemd and udev together, because that's how upstream ships it. But it's possible to compile and install just udev. Gentoo does that. LFS does too, except LFS does it by providing a custom Makefile to build just udev out of the combined systemd+udev tarball.
]]>bootchart
For a faster bootup (which, it seems, is what you really want), try e.g. e4rat.
]]>Not to mention that high IO/CPU usage doesn't mean waste, it means efficiency! You want your machine to boot fast? Load everything at once! Loading the same about of data at half the rate is obviously going to be slower.
But whats more important here is udev is dynamically loading functionality as its demanded, but its functionality your operating system needs to preform its job. Removing udev or lightening udev's load isn't going to make you boot faster, its just going to move the work to a different part of the boot process.
]]>If you want to go really minimal, go mdev with a non-systemd init, provided that you can deal with not having all the stuff I mentioned before among other things.
]]>However , arch current init system , systemd, depends on udev and afaik won't work with those alternatives.
In short, replacing udev will very likely also mean changing the init system.
I think forum user artoo has experimented with a combination of eudev and openrc, you could try asking him.
]]>...Not what I'm claiming. Just wondering why it registers the way it does, with apparently nothing to do.
Speaking in relative terms (and even that gives your description too much credit) with no basis to compare against is useless. I also question the validity of your statement that udev has "apparently nothing to do."
More to the point, I'm just trying to figure out if it CAN be removed, regardless of motive.
You can probably run 'systemctl mask systemd-udevd.socket' and see what life is like without udev. Things will very likely fail. You may not cleanly make it to a login prompt (systemd may wait for devices that never show up, as it expects to know the status via udev). You'll be missing ACLs on device nodes. Network devices may no longer have sysctl settings applied....
]]>falconindy wrote:Compiling modules into the kernel will only serve to extend your kernel boot time before the handoff to userspace.
How so? I've gone through the kernel config and stripped out everything not needed for my setup to run, using localmodconfig and a good deal of manual editing. Are you referring to a kitchen-sink kernel?
No, I'm referring to fact that the kernel will run the init code for all linked in modules before handing off control to userspace (the initramfs or PID 1), regardless of if or when the functionality provided by the modules is ever needed. Leaving your kernel modular lets userspace load the modules on an as-needed basis, and asynchronously with other bootstrap tasks.
The I/O dwarfs anything else by orders of magnitude.
This alone is not reason enough to claim that udev is inefficient or point to it as being a bottleneck.
]]>