remove_device does not trigger "remove" uevent
bobhenz-jabil opened this issue · comments
First of all... this package is awesome for testing!
I would like to request an enhancement though...
While add_device() triggers an "add" uevent. Currently remove_device() doesn't trigger a "remove" uevent. I find that I have to first call testbed.uevent(syspath, "remove") then call testbed.remove_device(syspath). This doesn't feel quite right to me since I don't have to do that when I'm adding a device.
In addition, the comment for remove_device() says "Note that this will also remove all child devices". So it would be really nice if a "remove" uevent was generated for the children as well when a device is removed. (Similar to what happens on hardware.)
Again, I appreciate your work here. Thank you.
You are right, it should trigger a remove uevent, for symmetry and also to better model what happens on a real system. I suppose nobody complained so far as that's a lot less common than adding 😁
I'll try to work on this over the weekend, but if you want to give it a try, please do!
I might be able to look at it next week, I think the difficulty will be in generating uevents for the children but I need to understand the code better to understand how to do that.
Just to state what I see as the difficulties here (I might be wrong on some of this):
- A device can be added with the name
foo/bar/baz, or 3 devices could be added as children of each other calledfoo,bar,baz. I think the resulting directory structure would be the same right? - The remove event needs to include the attributes and properties that the add event contained.
Therefore, I have a design proposal:
A. A hidden file (e.g. .umockdev) is added into the directory of each added device. The existence of this file would mean a device was added at this level.
B. When a parent device is removed, the directory structure of all subdirectories under it would be walked (recursively) and any directory found with a file of that name in it, would have a uevent('remove') call made for it.
C. I don't know if the attributes and properties are already stored in the directory of devices, but if not (or if it's easier) the contents of the .umockdev file could be the properties and attributes sent with the add-event and these would be sent with the remove event.
@martinpitt: Does this sound like a good approach?
A device can be added with the name foo/bar/baz, or 3 devices could be added as children of each other called foo, bar, baz. I think the resulting directory structure would be the same right?
Not quite I think: Some directories in /sys are devices, and some are just "organizational groupings". For example, /sys/block/ is not a device, but /sys/block/loop0 is. I think a good indicator of this is the presence/absence of an uevent file.
The remove event needs to include the attributes and properties that the add event contained.
Apparently so, yes. I tested this with sudo modprobe scsi_debug and sudo rmmod scsi_debug while watching ```sudo udevadm monitor -e --udev.
The existing uevent file fulfils exactly the role of what you want to do with .umockdev. It is already the place where properties are stored, and when walking the directory tree downwards you can create remove events for all child directories which have an uevent file. That should give the right semantics I think.
Great! I will try to come up with a branch that implements this using the uevent file over the next week.