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

["Jim Crilly" <jim@why.dont.jablowme.net>]

On 02/07/06 01:46:11AM +0100, Pavel Machek wrote:
> On Po 06-02-06 19:37:13, Jim Crilly wrote:
> > On 02/07/06 12:51:40AM +0100, Rafael J. Wysocki wrote:
> > > Hi,
> > > 
> > > This point is valid, but I don't think the users will _have_ _to_ switch to the
> > > userland suspend.  AFAICT we are going to keep the kernel-based code
> > > as long as necessary.
> > > 
> > > We are just going to implement features in the user space that need not be
> > > implemented in the kernel.  Of course they can be implemented in the
> > > kernel, and you have shown that clearly, but since they need not be there,
> > > we should at least try to implement them in the user space and see how this
> > > works.
> > > 
> > > Frankly, I have no strong opinion on whether they _should_ be implemented
> > > in the user space or in the kernel, but I think we won't know that until
> > > we actually _try_.
> > > 
> > 
> > Some of the stuff belongs in userspace without a doubt, like the UI. But
> > why was the cryptoapi stuff added to the kernel if everytime someone goes
> > to use it people yell "That's too much complexity, do it in userspace!"?
> 
> For stuff that can't be reasonably done in userspace, like encrypted
> loop. And notice that cryptoapi does *not* yet contain LZW.
> 								Pavel
> 

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.

And I realize lzf compression isn't in the main kernel yet, but cryptoapi
was designed to be modular so that new things can be added later if
necessary and deflate is already there, so it's not like there's no
compression algorithms included yet.

Jim.