Hi Rafael.

On Fri, 2007-04-27 at 00:08 +0200, Rafael J. Wysocki wrote:
quoted text
> On Thursday, 26 April 2007 22:08, Nigel Cunningham wrote:
> [--snip--]
> > > And no, I'm not saying that my suggestion is the only way to do it. G=
o=20
quoted text
> > > wild. But the *current* situation is just broken. Three different thi=
ngs,=20
quoted text
> > > none of which people can agree on. I'd *much* rather see a conceptual=
ly=20
quoted text
> > > simpler approach that then required, but even more important is that =
right=20
quoted text
> > > now people aren't even discussing alternatives, they're just pushing =
one=20
quoted text
> > > of the three existing things, and that's simply not viable. Because I=
'm=20
quoted text
> > > not merging another one.
> > >=20
> > > In fact, I personally feel that I shouldn't even have merged=20
> > > userspace-swsusp, but if Andrew thinks it needs to be merged, my pers=
onal=20
quoted text
> > > feelings simply don't matter that much. I have to trust people. But y=
es,=20
quoted text
> > > as far as *I* am personally concerned, I think it was a mistake to me=
rge=20
quoted text
> > > it.
> >=20
> > Perhaps you should try to make an alternative yourself instead of
> > pushing us into making something we don't believe will work (my case) o=
r
quoted text
> > have already done but in a way you don't like (Rafael). Don't talk abou=
t
quoted text
> > Pavel cutting code. He's just acking/nacking what Rafael sends him.
>=20
> Well, I think that much of what Linus is saying indicates that he hasn't =
tried
quoted text
> to write any such thing himself. ;-)
>=20
> Anyway, I'm tired of all this thing.  Really.  I've just been trying to m=
ake
quoted text
> things _work_ more-or-less reliably in a way that Pavel liked and I reall=
y
quoted text
> didn't know that much about the kernel when I started.  In fact, I starte=
d as a
quoted text
> user who needed certain functionality from the kernel and that was not th=
ere
quoted text
> at the time.  I've made some mistakes because of that (like the definitio=
ns of
quoted text
> the ioctl numbers in suspend.h - this was just a rookie mistake, and I'm
> ashamed of it, but _nobody_ catched it, although I believe many people we=
re
quoted text
> looking at the patch).
>=20
> Now that I know much more than before, I can say I agree with Linus on hi=
s
quoted text
> opinion about the separation of s2ram form the snapshot/restore functiona=
lity
quoted text
> (I'll call it 'hibernation' for simplicity from now on).  It should be do=
ne,
quoted text
> because it would make things simpler and cleaner.  Still, it will be diff=
icult
quoted text
> to do without screwing users en masse and that's my main concern here.
>=20
> I don't agree that we don't need the tasks freezer for suspending and
> hibernation.  We need it, because we need to be sure that the (other) tas=
ks
quoted text
> will not get us in the way, and that also applies to kernel threads (and =
I
quoted text
> don't think the tasks freezer is 'screwing' them, BTW).
>=20
> I agree that the userland interface for swsusp is not very nice and I'm g=
oing
quoted text
> to do my best to clean that up.  I hope that someone will help me, but if=
 not,
quoted text
> then that's fine.  OTOH, it's difficult, if not impossible, to do a
> userland-driven hibernation in a completely clean way.  I've tried that a=
nd I'm
quoted text
> not exactly satisfied with the result, although it works and some distros=
 use
quoted text
> it.  I wouldn't have done it again, but then I'm going to support the exi=
sting
quoted text
> users, as I promised.
>=20
> Now, I think that the hibernation should better be done completely in the
> kernel, because that's just conceptually simpler, although some data exch=
ange
quoted text
> with the user land may be acceptable for some optional fancy stuff.  I'm =
also
quoted text
> tierd of the endless "to merge or not to merge suspend2" discussions that=
 just
quoted text
> lead to nowhere.  For these reasons I declare that I'm ready to cooperate=
 with
quoted text
> Nigel on integrating as much of suspend2 as reasonably possible into the
> existing infrastructure, under the following conditions:
> - we don't remove the existing user-visible interfaces

I don't want to remove user visible interfaces either (I understand that
you mean the ioctls by that?). Perhaps we can find a way to make them
still usable with a more in-kernel solution (ie some things become
noops?).

quoted text
> - we work on one piece of code at a time

Sure. We should spend some time discussing and planning beforehand so we
don't waste time and effort writing and rewriting.

quoted text
> - we avoid code duplication, as much as possible

No problem there.

quoted text
> - we avoid using open-coded things, if possible

Regarding open-coded things, I assume you're referring to the extents. I
would argue that they're not open-coded because list.h implements doubly
linked lists, and extents use a singly linked list. That said, I suppose
we could make the extents doubly linked and use list.h, even though that
would be a waste of 4/8 bytes per extent.

quoted text
> - if we don't agree on something, we ask someone wiser (volunteers welcom=
e ;-))

Absolutely!

quoted text
> If that's acceptable, we can start tomorrow.  In the process, we can try =
to
quoted text
> separate the hibernation code paths from the s2ram ones, but that will re=
quire
quoted text
> a lot of knowledge about things that neither me nor Nigel, AFAICT, are ve=
ry
quoted text
> familiar with, like writing device drivers.

Yes.

Thanks for this email. It's really encouraging, and I'm more than glad
to work with you. Unfortunately, as you've seen me keep saying already,
I have very limited time to work on this. Thankfully you seem to have
more, and Pekka has also stepped up to help, so maybe we can make good
forward progress despite my limitations.

Regards,

Nigel