On Monday, 14 of April 2008, Benjamin Herrenschmidt wrote:
quoted text
> 
> > 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. :-)
 
quoted text
> 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.

quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/