Re: [RFC][PATCH 2/2] Convert several sysdev users to using struct syscore_ops

[Rafael J. Wysocki]

On Friday, March 11, 2011, Greg KH wrote:
> On Thu, Mar 10, 2011 at 01:34:02AM +0100, Rafael J. Wysocki wrote:
> > Some subsystems need to carry out suspend/resume and shutdown
> > operations with one CPU on-line and interrupts disabled and they
> > define sysdev classes and sysdevs specifically for this purpose.
> > This leads to unnecessarily complicated code and excessive memory
> > usage, so switch them to using struct syscore_ops objects for this
> > purpose instead.
> 
> Heavily-Acked-by: Greg Kroah-Hartman <gregkh@xxxxxxx>
> 
> :)

Heh, thanks!

> Do you want to resend this with a signed-off-by and your first one so I
> can apply it to my tree, or do you want to take it through yours?

Well, I'm going to resend with sign-offs anyway.  Besides, I'm not sure if
I should split [2/2] into a few smaller patches.  At least the stuff outside
of arch/x86 should be done in separate patches IMHO.

Apart from this, there are other architectures using sysdevs for defining
"very late" and "very early" PM callbacks, ARM in particular (that one is going
to be fun to untangle).

I thought about two different possible ways forward:

(1) Push [1/2] and the patches converting things that x86 depends on first,
    followed perhaps by a patch introducing something like
    CONFIG_ARCH_NO_SYSDEV_OPS that would simply disable
    sysdev_{suspend|resume|shutdown}() (x86 would set it).  The other arches
    might then be converted over time.

(2) Prepare patches converting everything that can be converted in the tree
    and push them all in one shot.

The advantage of (1) is that we can start making changes RSN and the
advantage of (2) seems to be that we may avoid some potential suspend/resume
ordering issues on non-x86 architectures that may arise in principle if some
subsystems are converted to using struct syscore_ops while the others are
not (syscore_suspend() is executed after sysdev_suspend(), so if we move
something from the latter to the former, it may end up being executed after
things that it was executed before previously).

Please let me know what your opinion is.

> thanks again for doing this.

No big deal really. :-)

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/