Hi On Mon, Sep 15, 2014 at 4:22 PM, John Haxby <john.ha...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel