Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964811AbWBGA74 (ORCPT ); Mon, 6 Feb 2006 19:59:56 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964921AbWBGA74 (ORCPT ); Mon, 6 Feb 2006 19:59:56 -0500 Received: from atpro.com ([12.161.0.3]:45572 "EHLO atpro.com") by vger.kernel.org with ESMTP id S964811AbWBGA7z (ORCPT ); Mon, 6 Feb 2006 19:59:55 -0500 From: "Jim Crilly" Date: Mon, 6 Feb 2006 19:59:31 -0500 To: Pavel Machek Cc: "Rafael J. Wysocki" , Nigel Cunningham , suspend2-devel@lists.suspend2.net, Lee Revell , linux-kernel@vger.kernel.org Subject: Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Message-ID: <20060207005930.GD31153@voodoo> Mail-Followup-To: Pavel Machek , "Rafael J. Wysocki" , Nigel Cunningham , suspend2-devel@lists.suspend2.net, Lee Revell , linux-kernel@vger.kernel.org References: <20060201113710.6320.68289.stgit@localhost.localdomain> <1139251682.2791.290.camel@mindpipe> <200602070625.49479.nigel@suspend2.net> <200602070051.41448.rjw@sisk.pl> <20060207003713.GB31153@voodoo> <20060207004611.GD1575@elf.ucw.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060207004611.GD1575@elf.ucw.cz> User-Agent: Mutt/1.5.11+cvs20060126 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2126 Lines: 46 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. - 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/