On Monday, 14 of April 2008, Benjamin Herrenschmidt wrote: > > > Well, I'm not sure and I'm not going to introduce the change right now, after > > the paches have been included in -mm. > > > > That would require quite some changes in the core code that I'd prefer to > > avoid for now. We can do something like this in a separate patch series after > > the present one settles down a bit. > > I disagree. Okay, so we have different opinions. :-) > Doing it later would introduce yet another major semantic change. > > I think we should get it right now. There's no hurry in pushing things > especially if they aren't quite right. >From my point of view, they are as right as they can be at the moment. Besides, maintainig a set of patches like this so that it always applies to a tree that's continuously changing under it is far from funny. I'm not going to do it much longer, that's for sure. > The ability for prepare() callbacks to sync with userland, > request_firmware, etc... is an important feature that's been needed for > some time imho. Well, if we put ->prepare() before the freezer, what can it actually do? Certainly nothing that will block any (user space) task, because the freezer won't work after that. So, all of the significant suspend work, like blocking tasks using the device etc., will have to be done by ->suspend(). Will that be convenient? I'm not sure. I'm not even sure that would be _doable_ at all. The point of view depends on what you think ->prepare() should be used for and I'm sure you have some specific cases in mind. However, are they generic enough? Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
