Comment # 20 on bug 1078358 from Mario Goppold

(In reply to Joey Lee from comment #18)
> (In reply to Mario Goppold from comment #16)
> > (In reply to Joey Lee from comment #13)
> > > (In reply to Mario Goppold from comment #10)
> > > > (In reply to Joey Lee from comment #9)
> > > > > (In reply to Mario Goppold from comment #8)
> > > > > > Here is my Log:
> > > > > > 
> > > > > >   virtserv2:~ # mv /usr/lib/udev/rules.d/80-acpi-container-hotplug.rules
> > > > > > _usr_lib_udev_rules.d_80-acpi-container-hotplug.rules
> > > > > >   virtserv2:~ # awk '/^processor/ {S+=1}END{print S}' /proc/cpuinfo
> > > > > >   24
> > > > > >   virtserv2:~ # udevadm trigger --verbose > udevadm_trigger.log 2>&1
> > > > > >   virtserv2:~ # awk '/^processor/ {S+=1}END{print S}' /proc/cpuinfo
> > > > > >   24
> > > > > >   virtserv2:~ # mv _usr_lib_udev_rules.d_80-acpi-container-hotplug.rules
> > > > > > /usr/lib/udev/rules.d/80-acpi-container-hotplug.rules
> > > > > >   virtserv2:~ # udevadm trigger --verbose > udevadm_trigger_2.log 2>&1
> > > > > >   virtserv2:~ # awk '/^processor/ {S+=1}END{print S}' /proc/cpuinfo 
> > > > > >   4
> > > > > >   virtserv2:~ # awk '/^processor/ {S+=1}END{print S}' /proc/cpuinfo
> > > > > >   1
> > > > > > 
> > > > > > The Logfiles udevadm_trigger.log and udevadm_trigger_2.log looks like the
> > > > > > first attachment and does not differ.
> > > > > 
> > > > > I have checked the src/udev/udevadm-trigger.c code in systemd. It makes
> > > > > sense for "udevadm trigger" triggers the CHANGE event to container because
> > > > > "change" is the default action for "udevadm trigger".
> > > > > 
> > > > > If you still want to use "udevadm trigger" but do not want the
> > > > > 80-hotremove-acpi-container.rules to be triggered. Please run:
> > > > > 
> > > > > $ ln -s /dev/null /etc/udev/rules.d/80-hotremove-acpi-container.rules
> > > > 
> > > > yes, I moved the file away and everything will be ok till the next
> > > > udev-update. 
> > > > I think the rule should be much more special than it is now, maybe with
> > > > vendor or  SUBSYSTEM!="cpu" or ...
> > > 
> > > The "udevadm trigger" triggers CHANGE event to _all_ devices. Why you want
> > > to do that after you add a rule about USB?
> > > 
> > > On your machine, there have ACPI0004 container that it collects CPUs. If you
> > > trigger CHANGE event to container from user space, then the children devices
> > > (CPUs in this case) will be offline by the 80-hotremove-acpi-container rule.
> > > Why you want to trigger CHANGE event to all devices?
> > 
> > 
> > Because I did not know that it would be necessary to limit to a subsystem
> > and over the years I have not seen such behavior. 8 out of 10 search results
> > for udev reload do not mention the need for any restrictions. 
> 
> In kernel ACPI subsystem, it emits CHANGE event to userland to indicate that
> the device will be removed. Then userland should performs necessary cleaning
> job and offline the children devices.
> 
> The "udevadm trigger" didn't get side effect before because udev doesn't
> have rule to handle the CHANGE event. I was curious why the "udevadm
> trigger" must be performed after adding a new rule?
> 
> > 
> > Once again: In the comment of the rule stand: "ACPI0004 container offline
> > for Huawei Kunlun" but I can not see that the actual rule reflect these
> > specific machine. Have this no vendor id?
> 
> We have tested this rule for handling the CHANGE event on Kunlun, but this
> behavior doesn't specific on Kunlun. The CHANGE event is used by  ACPI
> container in kernel that it should be handled by user space. 
> 
> Please aware that the "udevadm trigger" will emit CHANGE event to ALL
> devices. Which means that all udev rules that handle CHANGE event will be
> performed.
> 
> The 80-hotremove-acpi-container.rules is a default rule for ACPI container
> offline. I will update the comment of the rule to mention that how to
> disable it.

OK, I understand the changes and also that "udevadm trigger" globally triggers
events that may not be wanted. 

The use case for a trigger is: plug a device and realize that it was not
correctly initialized. Add a useful udev rule and you dont want to go
downstairs to unplug and plug the device again.

In such caces I will restrict the trigger to the devices I wand to change, for
example:

   udevadm trigger --verbose --type=devices --subsystem-match=usb

For me, the incident is complete. Are there any objections?