Hi.
Matthew Garrett wrote:
On Thu, Feb 21, 2008 at 11:40:06AM +1100, Nigel Cunningham wrote:
Matthew Garrett wrote:
No, with a freezer-based model you can basically *never* suspend to
anything related to FUSE or a userspace USB device or anything involving
userspace iSCSI initiators or whatever. Sure, there are cases where
moving away from the current model doesn't buy you anything, but that
doesn't mean that the current model is a good thing. It's not. The
freezer is a fundamentally broken concept.
Putting drivers and filesystems in userspace is the fundamentally broken
concept. Not just when it comes to the freezer. The whole idea is
inherently racy. You can draw silly diagrams about how the freezer
supposedly works in LCA slides and spread FUD as much as you like. In
the end, though, it's not nearly as hit-and-miss as you say, and
replacing the freezer with a kexec based freezer is only going to create
as many problems as it removes.
I'm really not interested in debating the matter. There are all sorts of
potential uses for the freezer, but hibernation isn't one of them. We
*need* to get rid of the freezer for suspend to RAM (because a band-aid
to ensure atomicity is kind of pointless when the operation you're
entering is inherently atomic), and once all the drivers are able to
deal with that then it's trivial to get rid of it for hibernation as
well. Arguing that the reality of userspace drivers is broken doesn't
help here. It's what we have to work with.
Re suspend to ram, I agree. No argument there. Re hibernation, I think
your assertion that it will be trivial to get rid of it for hibernation
is just plain wrong. Perhaps you don't understand the issues as well as
you think you do.
Re arguing that the reality of userspace drivers is broken doesn't help
here: Yeah, I know. But sometimes if you point out broken ideas for long
enough, people do actually listen. Or you learn. Or both.
Frankly, I don't want to debate the issue either. What I really want is
just to have a hibernation implementation that works, is flexibile,
reliable and quick, and one that I don't have to keep maintaining.
Unfortunately for me, most people seem to be more concerned with fixing
hypothetical problems than with giving users something they can actually
use.
You're looking at a tiny amount of memory when compared to current
systems. It's really not a problem.
Please, quantify 'tiny'. In embedded, 5MB can be too much. I've worked
on embedded solutions. I'm not pulling problems out of thin air.
Then the in-kernel solution has already lost anyway, and I'm desperately
unconcerned about out of tree stuff.
I know. I'd submit it, or work on breaking it into pieces and submitting
them one at a time, but that seems to me to be a waste of time.
Nigel
-
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