On Thursday, March 10, 2011, Kay Sievers wrote: > On Thu, 2011-03-10 at 01:31 +0100, Rafael J. Wysocki wrote: > > There are multiple problems with sysdevs, or struct sys_device objects to > > be precise, that are so annoying that some people have started to think > > of removind them entirely from the kernel. To me, personally, the most > > obvious issue is the way sysdevs are used for defining suspend/resume > > callbacks to be executed with one CPU on-line and interrupts disabled. > > Greg and Kay may tell you more about the other problems with sysdevs. :-) > > > > Some subsystems need to carry out certain operations during suspend after > > we've disabled non-boot CPUs and interrupts have been switched off on the > > only on-line one. Currently, the only way to achieve that is to define > > sysdev suspend/resume callbacks, but this is cumbersome and inefficient. > > Namely, to do that, one has to define a sysdev class providing the callbacks > > and a sysdev actually using them, which is excessively complicated. Moreover, > > the sysdev suspend/resume callbacks take arguments that are not really used > > by the majority of subsystems defining sysdev suspend/resume callbacks > > (or even if they are used, they don't really _need_ to be used, so they > > are simply unnecessary). Of course, if a sysdev is only defined to provide > > suspend/resume (and maybe shutdown) callbacks, there's no real reason why > > it should show up in sysfs. > > > > For this reason, I thought it would be a good idea to provide a simpler > > interface for subsystems to define "very late" suspend callbacks and > > "very early" resume callbacks (and "very late" shutdown callbacks as well) > > without the entire bloat related to sysdevs. The interface is introduced > > by the first of the following patches, while the second patch converts some > > sysdev users related to the x86 architecture to using the new interface. > > > > I believe that call sysdev users who need to define suspend/resume/shutdown > > callbacks may be converted to using the interface provided by the first patch, > > which in turn should allow us to convert the remaining sysdev functionality > > into "normal" struct device interfaces. Still, even if that turns out to be > > too complicated, the bloat reduction resulting from the second patch kind of > > shows that moving at least some sysdev users to a simpler interface (like in > > the first patch) is a good idea anyway. > > Do I read that right? We get rid of the entire dance of creating > sysdevs/sysdev_classes and the pointless and broken stuff in /sys? That's the plan at least. > We just dynamically maintain a list of devices/operations, which is > list-executed when needed? > > These new "core" operations are not included in every device but only > global per subsystem, just like the sysdev_class did earlier? Yup. > Looks all like a nice plan to me. Good. :-) Thanks, Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
