On Mon, 14 Apr 2008, Benjamin Herrenschmidt wrote: > > > To avoid breaking things (from the functional point of view) unnecessarily. > > > > In short, I don't really see the difference between moving ->prepare() before > > the freezer and droppig the freezer, which I'm not going to do right now. > > I believe the use of prepare for things like request_firmware etc... is > worth the effort of fixing the known breakage of not having the freezer > while preventing insertion of new devices (mostly USB). I used USB as an example simply because that's what I'm familiar with. Don't be so quick to assume the rest of the kernel is trouble-free. > In fact, it > won't be such a big issue as the core should/will return an error from > attempting to add the device in that case. But it _would_ be a regression -- and everyone knows how much Linus and Andrew dislike regressions. :-) Now, I don't see what the big deal is here. We all agree that it would be nice and appropriate if drivers could do things like request_firmware() during prepare(). But for the moment they can't. It's not like this is some tremendous hardship -- you aren't going to have to rip out all the existing prepare() implementations and rewrite them, because they don't exist yet! All it means is that the full conversion to the new interface will be a multi-step process. Right now we add the new callbacks. Later on we make it safe to move the freezer after prepare. Later still we eliminate the freezer altogether from suspend. (Hibernation is a separate matter...) Alan Stern -- 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
