Am Sat, 28 Feb 2015 09:38:27 +0100 schrieb Michael Biebl <biebl@xxxxxxxxxx>: > I don't think working around this in udev/systemd is a good idea. Idealy and in the long run, the kernel drivers should keep state, yes. But until then, better not to make releases with default configurations that deliver serious problems (excessive hardware wear, data loss) to the users. I believe before things stadardized around systemd and udev, packages like hdparm, laptop-mode-tools, pm-utils, acpi-support, gnome-power-manager, and more, all tried to work around problems with block devices loosing state. Unfortunately, accumulating a large mess and interferences resuling in releases with many bugs in this regard. Now the situation can improve a lot, if we can say packages are safe if they use udev rules to initialize devices. (As the kernel keeps state, or systemd centrally triggers a udev change event where this is not (yet) the case.) > most of those custom settings aren't applied via udev rules > anyway. Which settings were you refering to? With current versions hdparm, mdadm, etc. all seem to ship udev rules. And that seems to be the proper way to configure the standard hot-pluggable systems of today. (leaving aside embedded, non-systemd, non udev systems) -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
