rules: drivers - always call kmod, even when a driver is bound to the device

On Sat, Jul 20, 2013 at 12:56 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> After a recent change present in 3.11-rc1 there is a driver, called processor,
> that can be bound to the CPU devices whose sysfs directories are located under
> /sys/devices/system/cpu/.  A side effect of this is that, after the driver has
> been bound to those devices, the kernel adds DRIVER=processor to ENV for CPU
> uevents and they don't match the default rule for autoloading modules matching
> MODALIAS:
>
> DRIVER!="?*", ENV{MODALIAS}=="?*", IMPORT{builtin}="kmod load $env{MODALIAS}"
>
> any more.  However, there are some modules whose module aliases match specific
> CPU features through the modalias string and those modules should be loaded
> automatically if a compatible CPU is present.  Yet, with the processor driver
> bound to the CPU devices the above rule is not sufficient for that, so we need
> a new default udev rule allowing those modules to be autoloaded even if the
> CPU devices have drivers.
core: correct dbus parameter direction
man: udev - add section about hwdb
shared: fix build on !x86
rules: net, tty description - ask hwdb explicitly for pci data
man: wording and grammar updates

This includes regularly-submitted corrections to comma setting and
orthographical mishaps that appeared in man/ in recent commits.
NEWS: prepare half a NEWS file for upcoming 206
systemd-tmpfiles-setup-dev: remain after exit

Without this, tmpfiles-setpu-dev  would be re-run if any other service,
which pulls in basic.target, was started after setup-dev was finished
and before basic.target was active.
kmod-static-nodes: remain after exit
TODO: update
bus: update for kdbus changes
NEWS: fix mistake
build-sys: prepare 206
README Bump minimum required version of kmod

See edeb68c53f1cdc452016b4c8512586a70b1262e3.
man: Fix copy&paste error
remove left-over initrd time stamp handling
remove systemd-timestamp from sources

No sense in keeping this around if support for reading RD_TIMESTAMP has
been removed.
core: synchronously block when logging

Previously, the logging sockets were asynchronous and if clogged we'd
lose messages. We did this to be extra careful given that PID 1 might
need to spawn the logging daemon as response to PID 1's own log messages
and we really should avoid a deadlock in that case.

As it turns out this causes loss of too many messages, hence make the
socket blocking again, however put a time limit on it to avoid unbounded
deadlocks in the unlikely case they happen.

https://bugs.freedesktop.org/show_bug.cgi?id=66664
journal: immediately sync to disk as soon as we receieve an EMERG/ALERT/CRIT message
README: Bump to Linux 3.0

Support for writing to cgroup.procs was introduced in 3.0