Re: [swsusp] separate snapshot functionality to separate file
From: Pavel Machek (pavel_at_ucw.cz)
Date: 10/05/05
- Previous message: linas: "[PATCH] rpaphp: PCI Hotplug crash on PHB DLPAR add"
- In reply to: Rafael J. Wysocki: "Re: [swsusp] separate snapshot functionality to separate file"
- Next in thread: Rafael J. Wysocki: "Re: [swsusp] separate snapshot functionality to separate file"
- Reply: Rafael J. Wysocki: "Re: [swsusp] separate snapshot functionality to separate file"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 5 Oct 2005 02:06:58 +0200 To: "Rafael J. Wysocki" <rjw@sisk.pl>
Hi!
> > Well, same cleanup can be done after the split, just as easily.
> >
> > > 3) some cleanups are due before the splitting (eg. function names, the removal
> > > of prepare_suspend_image() etc.),
> >
> > Split does not prevent you from doing the cleanups.
>
> No, it doesn't, but the flow of changes would be easier to follow if the
> cleanups were made first (ie. cleanup -> smaller and simpler code ->
> split).
I wanted to have a "this changes nothing" patch first. Cleanups in
front would be trickier to do because period of "settle down" is
needed before split. We now had quite a long "settle down" period, so
I've seen opportunity to do the split now.
> > No. It needs to be controlled by storage-handling parts, so that
> > snapshot-handling parts become nice library.
>
> You are right, I have confused the sides. I should have said like that:
> The snapshot-handling part makes some functions available to the
...
> part need not care for what happens to the pages of data send to the
> storage-handling parts as long as it can receive them back in the same
> order in which they have been sent.
Nicely said.
> > That is ugly. snapshot needs to be called from storage handling parts,
> > and then interface can become much simpler:
> >
> > struct pbe *sys_snapshot();
> >
> > snapshots a system, then you can save it in any way you want. And
> >
> > void sys_restore(struct pbe *);
> >
> > . Simple, eh?
>
> Well, aren't there any problems with handling kernel addresses from the user
> space and vice versa?
Nothing we could not handle. Kernel needs to use get_user, while
userspace needs to seek/read/write on /dev/kmem (when accessing "the
other" addresses).
> Anyway, I think on resume we should send data from the user space to the
> kernel and let the kernel arrange them in memory instead of placing them in
> memory directly from the used space. By symmetry, on suspend we should send
> data from the kernel to the user space instead of allowing the users space
> to read memory at will. IMO the arrangement of the data in memory should
> not be visible to the user space at all.
I thought about that -- user/kernel interface would certainly be nicer
-- but I do not think it is feasible without writing a lot of code.
[I agree that assymetry I have in there is ugly, but I don't see a way
to do alloc_pagedir() in userspace, and I'd like to keep page
relocation in userspace.]
> Still I'm afraid in the future we'll be moving some functions between
> snapshot.c and swsusp.c back and forth ...
We may have to move function or two, but I think nothing too dramatic
will happen.
Pavel
-- if you have sharp zaurus hardware you don't need... you know my address - 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/
- Previous message: linas: "[PATCH] rpaphp: PCI Hotplug crash on PHB DLPAR add"
- In reply to: Rafael J. Wysocki: "Re: [swsusp] separate snapshot functionality to separate file"
- Next in thread: Rafael J. Wysocki: "Re: [swsusp] separate snapshot functionality to separate file"
- Reply: Rafael J. Wysocki: "Re: [swsusp] separate snapshot functionality to separate file"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
