Re: what the patches do Re: [RFC 10/15] PM / Hibernate: user, implementuser_ops reader

From: Nigel Cunningham
Date: Thu Mar 25 2010 - 16:35:01 EST


Hi.

On 26/03/10 07:29, Rafael J. Wysocki wrote:
On Thursday 25 March 2010, Nigel Cunningham wrote:
Hi.

On 26/03/10 07:14, Rafael J. Wysocki wrote:
On Thursday 25 March 2010, Nigel Cunningham wrote:
Hi.

On 25/03/10 16:30, Pavel Machek wrote:
[...]

I have some problems with sws_module_ops interface (handcoded locking
is too ugly to live), but it is better than I expected. But there may
be better solution available, one that does not need two interfaces to
maintain (we can't really get rid of userland interface). What about
this?

Just picking up on that bracketed part: Can we flag the userland
interface (and uswsusp) as being planned for eventual removal now... or
at least agree to work toward that?

No, we can't.

I'm asking because if we're going to make a go of getting the in-kernel
code in much better shape, and we have Rafael, Jiri and I - and you? -
all pulling in the same direction to improve it, there's going to come a
point (hopefully not too far away) where uswsusp is just making life too
difficult, and getting rid of it will be a big help.

We're not dropping user space interfaces used by every distro I know of.

So what's your long term plan then?

First, improve the in-kernel thing, second, switch people to it, _then_ remove
the s2disk interface (after we're reasonably sure it's not used by any major
distro) and _finally_ simplify things after it's been removed.

Does that sound reasonable?

Well, that's pretty much what I was thinking too - improve then remove. I was just suggesting that we flag now that this is our plan, so it doesn't come as a surprise to anyone later and we can proceed more quickly than might otherwise be the case. I'm imagining it won't take long to get uswsusp features into the kernel code.

Regards,

Nigel
--
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/