[lkml]   [2005]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [swsusp] separate snapshot functionality to separate file

    > > 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.
    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-10-05 02:09    [W:0.028 / U:2.856 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site