On Fri, Sep 12, 2014 at 11:03 AM, Kay Sievers <k...@vrfy.org> wrote: >> Here, the default >> action is almost a trivial configuration... but not the only possible >> desired configuration. >> >> Can I ask your reasoning for CPU hotplug behaviour not being the role of >> udev to fulfill? If that's not the right place, where do you believe >> would be the appropriate alternative? > > As explained several times, there is no point in mis-using udev to > unconditionally react to kernel events to trigger things in the kernel > again. That is not how driver/device binding works for all the other > subsystems on Linux.
We can now rename network interfaces based on their MACs upon attach without involving the kernel? And reconfiguring a loaded kdump image upon memory change no longer requires doing anything in the kernel? I must have missed a piece of documentation somewhere. I also didn't realize that having a configurable action made something "unconditional". I thought that "unconditional" was in direct opposition to "configurable". I need a new technical dictionary to help me understand these new terms. If it isn't clear, those statements have a liberal coating of sarcasm to drive the points home. >> I'm hoping you have another place in mind. > > The kernel itself or any other custom facility. This stuff has no > place in default/upstream udev, it is the wrong way to do things in > default setups. udev processes kernel events in a programmatic fashion. That has always been its purpose, stated in a single sentence, without exceptions. There has never been some sort of holistic mission for udev with a spiritual direction on the "way to do things". udev processes events and allows configurable actions to handle them, full stop. What we do with those events is udev's rule configuration. Some of those actions do involve telling the kernel to do something in addition to the original event; see the two examples above (though these are not the only ones in common use, obviously). If there were no need to configure differing reactions to kernel events, rules.d wouldn't exist. All that is being proposed here is to offer a default reaction to a CPU add event -- the configuration for which can be changed by a system administrator, distro, or tool just by changing a text file, rather than recompiling a kernel. Making the action configurable, by definition, means that it is *not* unconditional. -- -- Todd Vierling <t...@duh.org> <t...@pobox.com> _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel