[systemd-devel] [PATCH] Add the CPU hotplug rule

David Herrmann dh.herrmann at gmail.com
Mon Sep 15 07:47:59 PDT 2014


Hi

On Mon, Sep 15, 2014 at 4:22 PM, John Haxby <john.haxby at oracle.com> wrote:
> I really appreciate proper explanations, thank you.

Quite simple: We want to avoid calling into udev and back into the
kernel if we there's a way to skip this step. That is, the default
should work without udev.

Reasons:

* We want init=/bin/bash or anything else to work. Or more precisely:
I don't care for init=/bin/bash, but others do. Lets not make their
life miserable, but make defaults work with init=/bin/bash if possible

* You can use your new shiny kernel with CPU hotplugging together with
an old udev user-space and the default will just work. Same is true
for any other new bus type. But if we require udev rules for the
_default_ to work, you need to install udev rules (or update udev
respectively) just to make the default work. That already sounds
backwards, doesn't it? Furthermore, this seems cumbersome and kinda
makes it no longer the "default", right?

* It is wasted time and wasted resources to call into user-space to
trigger the default action. If something is the default, it should
just happen and not require a bunch of messages between different
services. Instead, the opposite should be true: If you don't want the
default actions, tell the kernel about it and only then you should get
hooked into the decision.
Imagine all decisions made by the kernel go through udev. It would
slow down systems considerably. So lets keep it down unless there's
strong reason to send it through udev.

* We want people to chose *sane* defaults. Everywhere. So if the
kernel default is *sane*, why do we need an udev rule?

Obviously, there're exceptions. Mostly backwards compatibility and
interactions with totally backwards subsystems. But if there's a
chance to reduce the amount of default udev rules, I bet you get
praised for each and every properly removed rule.

Does that make sense? Maybe Kay has additions/corrections, but I think
this explanation should be fairly straightforward.

Thanks
David


More information about the systemd-devel mailing list