Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Jim Crilly]

On 02/06/06 08:19:02PM -0500, Lee Revell wrote:
> On Mon, 2006-02-06 at 19:59 -0500, Jim Crilly wrote:
> > I guess reasonable is a subjective term. For instance, I've seen quite
> > a few people vehemently against adding new ioctls to the kernel and
> > yet you'll be adding quite a few for /dev/snapshot. I'm just of the
> > same mind as Nigel in that it makes the most sense to me that the
> > majority of the suspend/hibernation process to be in the kernel. 
> 
> No one is saying that ANY new ioctls are bad, just that the KISS
> principle of engineering dictates that it's bad design to use ioctls
> where a simple read/write to a sysfs file will do.
> 

I understand that, but shouldn't the KISS principle also be applied to
the user interface of a feature? As it stands it looks like Suspend2
is going to be a lot simpler for users to configure and get right than
uswsusp. As long as you have Suspend2 enabled in the kernel it 'just
works', even if you don't have the userland UI it'll still suspend and
resume just without the progress bars. There is still some room for error
with things like forgetting to enable the swap writer and then attempting
to suspend to a swap device or making lzf a module and forgetting to
load it before resuming from a compressed image, but those are no worse
than any other kernel option.

With uswsusp it'll be more flexible in that you'll be able to use any
userland process or library to transform the image before storing it, but
the suspend and resume processes are going to be a lot more complicated.
For instance, how are you going to tell the kernel that you need the
uswsusp UI binary, /bin/gzip and /usr/bin/gpg to run after the rest of
userland has been frozen?

Jim.
-
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/