Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 7 Jul 2001 09:50:48 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 7 Jul 2001 09:50:38 -0400 Received: from panic.ohr.gatech.edu ([130.207.47.194]:21960 "HELO havoc.gtf.org") by vger.kernel.org with SMTP id ; Sat, 7 Jul 2001 09:50:18 -0400 Message-ID: <3B471399.1D6BBED6@mandrakesoft.com> Date: Sat, 07 Jul 2001 09:50:17 -0400 From: Jeff Garzik Organization: MandrakeSoft X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eugene Crosser Cc: linux-kernel@vger.kernel.org Subject: Re: [Acpi] Re: ACPI fundamental locking problems In-Reply-To: <9i73bg$psv$1@pccross.average.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Eugene Crosser wrote: > > In article , > Alexander Viro writes: > > >> Doesn't the approach "treat a chunk of data built into bzImage as > >> populated ramfs" look cleaner? No need to fiddle with tar format, > >> no copying data from place to place. > > > > What the hell _is_ "populated ramfs"? The thing doesn't live in array > > of blocks. Its directory structure consists of a bunch of dentries. > > I am stupid. But the point still stays: having an image of pre-populated > filesystem (some other than ramfs) that you only need to load into > RAM seems more sutable than parsing tar format. Maybe (probably) I am > missing something. Yeah -- we build all this stuff dynamically. struct file, struct inode, etc. You could store them on disk as they would be represented in memory, but this would be incredibly inefficient because of all the runtime structures unnecessary on disk, and because of all the fixups and checks you would have to perform on the data in the images after they magically appear in memory. Reading a tarball is the distillation of what you describe into efficient form :) -- Jeff Garzik | A recent study has shown that too much soup Building 1024 | can cause malaise in laboratory mice. MandrakeSoft | - 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/