The example I quoted earlier about binding during a suspend will do. I
agree that we can and should try to prevent it from ever occurring.
Read and write are a problem only in that fixing them would potentially
involve changing lots of drivers; I don't think they pose a serious
theoretical obstacle. (Lord knows what will happen with async I/O!)
Any other entry points to drivers are also potential problems, but it's
hard to say anything definite about them since they are so varied.
Yes.
Getting the PM core to resume a device before probing could be
difficult; in general it doesn't know enough about specific device
behaviors to do something like that. But the subsystem certainly ought
to take care of it. USB does.
Yes, bind/unbind/etc. should be deferred during a system suspend. But
it has to be done carefully, because these operations generally involve
locks that can't be released. They need to be prevented at their
source, not in the driver core. That's one reason why khubd needs to
be frozen (being part of the USB hub driver, it is the task responsible
for binding and unbinding drivers to USB devices).
Another thing to look out for is registration and unregistration of
drivers. These activities also cause bind/unbind operations. Note
that if userspace is frozen then neither insmod nor rmmod can run. :-)
All I/O to sysfs attributes passes through the routines in fs/sysfs/*.
It could be blocked there. (But if userspace is frozen it won't need
to be.)
That's certainly true of block devices, whose drivers use the block
subsystem. It's not true for lots of other devices, though.
In my experience, most non-block drivers do not have any queue of
pending I/O operations. They simply carry out requests as they arrive.
Alan Stern
-
