From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nathan Gray Subject: Re: DSDT in initrd Date: Wed, 21 May 2003 00:23:12 -0700 Sender: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Message-ID: References: <20030520180149.GJ31518@parcelfarce.linux.theplanet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Return-path: Errors-To: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-acpi@vger.kernel.org Markus Gaugusch wrote: > On May 20, Matthew Wilcox > wrote: >> No. Linus will take one look at it and vomit. > Because I'm scanning raw initrd data? Can anybody give me hints or a > better solution? I'm willing to improve it, but I don't think that it is > easy to do. I continue to think that the proper solution is a separate kernel parameter acpi_tables=/boot/tables.??? (with credit to the person who generalized this idea from the dsdt to all tables). I know you're concerned about fs drivers not being around, but if the kernel can find the initrd on the disk it should be able to find other files somehow. It depends on what you think the initrd is for, though. If it's just a generic pseudo-disk for early boot time then putting the acpi tables in is sensible, but if you think that certain specific things (e.g. modules) "belong" in it while others don't then maybe it'll be more of an issue. I guess my next question would be, is there a filesystem in the initrd, and if so can you implement your patch in a way that respects the filesystem abstraction rather than scanning the raw bytes. I'm not much of a kernel hacker myself, but I can see how people would be uncomfortable with the precedent it would set to allow that kind of raw byte scanning. Cheers, -Nathan -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge