Re: [swsusp] separate snapshot functionality to separate file
From: Pavel Machek
Date: Tue Oct 04 2005 - 19:07:40 EST
> > 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 ->
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.
> > 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
> 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
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/