[PATCH] overriding tables via initramfs in 2.6.1

[PATCH] overriding tables via initramfs in 2.6.1

[Dino Klein]

[-- Attachment #1: Type: text/plain, Size: 2660 bytes --]

Hello people,
I wrote a little patch to override multiple tables.
I ended up having to do this, because the DSDT patch out there wasn't enough 
- I wanted to modify the FACP table as well, so that throttling would work, 
as well as C3.
The patch is a patchwork of what I know about kernel programming and what 
I've seen around. It seems to be working fine (at least on my machine), but 
I can't guarantee anything.

First, here's a quickstart of how to use it:
1) make a directory - $DIR
2) cp $YOUR_INITRD_IMAGE $DIR/initrd.image
3) copy any table that you wish to replace into $DIR, and make sure that it 
is named according to it's signature; that is - if you want to change your 
DSDT, then make sure that the file you put in $DIR is named DSDT (all 
uppercase).
4) create a file $DIR/list that will contain a listing of all the files in 
$DIR (excluding "list"), each entry on a single line
5) cpio -o -c < list > new.cpio
6) gzip -9 new.cpio
7) cp new.cpio.gz /boot
8) now you use the new.cpio.gz as the initrd image that is passed to the 
boot loader (yep, that's it)

This works, and you get to keep your initrd image as well. This is because 
of the handling of the file passed off to the kernel _as_ the initrd image. 
It checks if it is a CPIO archive, and if it is, then it is unpacked onto 
the filesystem (rootfs). If it were the standard initrd image, then it would 
be copied to "/initrd.image", and later on used for inital mounts. In a 
nutshell, the initrd mounting code expects "/initrd.image", so using that 
little trick we are providing it.
However, in our CPIO archive we also have tables that we wish to override; 
they also will be created as files under "/", and later be used by the code 
I added to "drivers/acpi/osl.c". Whenever the ACPI subsystem(?) asks the OS 
whether it wants to override a particular table, the added code checks 
whether a file exists in "/" named as the signature of the table; if it 
exists, then the file is loaded into memory, then unlinked, and the table is 
returned to the ACPI subsystem.

Some catche/s:
If you start messing arround with the CPIO archive that resides in 
$KERNEL/usr, then you might get burned - it took me a while to figure out 
what is going on: the default archive created therre contains the entries 
"/dev", "/dev/console", and "/root". Apparently, that is the only way they 
are created, and the initrd code depends on it indirectly (it assumes "/dev" 
exists).

Well, hope this proves useful to someone.

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

[-- Attachment #2: acpi-table-override-patch-20040119.diff --]
[-- Type: application/octet-stream, Size: 2021 bytes --]

diff -Nru linux-2.6.1.orig/drivers/acpi/osl.c linux-2.6.1/drivers/acpi/osl.c
--- linux-2.6.1.orig/drivers/acpi/osl.c	2004-01-09 01:59:56.000000000 -0500
+++ linux-2.6.1/drivers/acpi/osl.c	2004-01-18 22:44:06.244225096 -0500
@@ -43,6 +43,13 @@
 
 #include <linux/efi.h>
 
+#include <linux/fs.h>
+#include <linux/unistd.h>
+asmlinkage long sys_unlink(const char *name);
+asmlinkage long sys_newstat(char * filename, struct stat * statbuf);
+asmlinkage long sys_read(int fd, void * buf, size_t count);
+
+
 
 #define _COMPONENT		ACPI_OS_SERVICES
 ACPI_MODULE_NAME	("osl")
@@ -226,10 +233,56 @@
 acpi_os_table_override (struct acpi_table_header *existing_table,
 			struct acpi_table_header **new_table)
 {
+	char file_name[6];
+	int fd;
+
+
 	if (!existing_table || !new_table)
 		return AE_BAD_PARAMETER;
 
+
 	*new_table = NULL;
+	// copy the table's name
+	file_name[0] = '/';
+	memcpy(file_name+1, existing_table, 4);
+	file_name[5] = 0;
+	printk(KERN_NOTICE "looking for table replacement: %s\n", file_name+1);
+	// attempt to open the file
+	fd = sys_open(file_name, O_RDONLY, 700);
+	if (fd>=0)
+	{
+		struct stat st;
+		int ret;
+
+
+		// find out the size
+		ret = sys_newstat(file_name, &st);
+		if (ret==0)
+		{
+			// allocate space for the table
+			*new_table = kmalloc(st.st_size, GFP_ATOMIC);
+			if (*new_table!=NULL)
+			{
+				// read in the table
+				ret = sys_read(fd, *new_table, st.st_size);
+				if (ret==st.st_size)
+				{
+					printk(KERN_NOTICE "Succsessfuly loaded table %s with %d bytes\n", file_name+1, (int)st.st_size);
+					goto table_override_success;
+				}
+				else printk(KERN_ERR "failed to read(); result - %d\n", ret);
+				kfree(*new_table);
+				*new_table = NULL;
+			}
+			else printk(KERN_ERR "failed to kmalloc() %d bytes\n", (int)st.st_size);
+		}
+		else printk(KERN_ERR "failed to stat %s\n", file_name);
+table_override_success:
+		sys_close(fd);
+		sys_unlink(file_name);
+	}
+	else printk(KERN_INFO "no replacement for table %s\n", file_name+1);
+
 	return AE_OK;
 }
 

Re: [PATCH] overriding tables via initramfs in 2.6.1

[Ducrot Bruno]

On Mon, Jan 19, 2004 at 03:43:32AM +0000, Dino Klein wrote:
> Hello people,
> I wrote a little patch to override multiple tables.
> I ended up having to do this, because the DSDT patch out there wasn't 
> enough - I wanted to modify the FACP table as well, so that throttling 
> would work, as well as C3.
> The patch is a patchwork of what I know about kernel programming and what 
> I've seen around. It seems to be working fine (at least on my machine), but 
> I can't guarantee anything.
> 

That seems to be good, but why not using already the
"ACPI DSDT in initrd" patch from Markus Gaugusch instead?

It is fairly trivial to modify it to get all tables overide and do
not require all of those files creation/deletion.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: [PATCH] overriding tables via initramfs in 2.6.1

[Dino Klein]

>That seems to be good, but why not using already the
>"ACPI DSDT in initrd" patch from Markus Gaugusch instead?
>
>It is fairly trivial to modify it to get all tables overide and do
>not require all of those files creation/deletion.
>
>--
>Ducrot Bruno


Well, someone would have to modify it :) also, you'd have to code in all the 
table names in advance, and make pointers for each one, thus adding more 
code to the patch.
other than that, I personally don't like appending stuff at the end of the 
initrd image. Handling files is much simpler, and this patch only modifies a 
single, so the changes are more localized.

_________________________________________________________________




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: [PATCH] overriding tables via initramfs in 2.6.1

[Bas Mevissen]

Ducrot Bruno wrote:
> 
> That seems to be good, but why not using already the
> "ACPI DSDT in initrd" patch from Markus Gaugusch instead?
> 
> It is fairly trivial to modify it to get all tables overide and do
> not require all of those files creation/deletion.
> 

That patch on itself is fine. But I think it is time for a more general 
way of adding stuff to an initrd that should be accessable for the 
kernel before the kernel is "really" running (for example bootsplash).

So I would propose to have a new kind of initial image that consists of 
an archive of all kinds of files. One of them is the initrd, of course.


Regards,

Bas.




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: [PATCH] overriding tables via initramfs in 2.6.1

[Dino Klein]

I think you should look into initramfs / early-userspace, because I think 
that's what it's intended for.
Check the 2.6.1/Documentation/early-userspace directory.
The files are unpacked pretty early, even before ACPI initialization. That's 
what my patch and Markus Gaugusch's patch are based on, the fact that 
initramfs/initrd are processed at such an early stage.


>Ducrot Bruno wrote:
>>
>>That seems to be good, but why not using already the
>>"ACPI DSDT in initrd" patch from Markus Gaugusch instead?
>>
>>It is fairly trivial to modify it to get all tables overide and do
>>not require all of those files creation/deletion.
>>
>
>That patch on itself is fine. But I think it is time for a more general way 
>of adding stuff to an initrd that should be accessable for the kernel 
>before the kernel is "really" running (for example bootsplash).
>
>So I would propose to have a new kind of initial image that consists of an 
>archive of all kinds of files. One of them is the initrd, of course.
>
>
>Regards,
>
>Bas.

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Re: [PATCH] overriding tables via initramfs in 2.6.1

[Ducrot Bruno]

On Tue, Jan 20, 2004 at 04:44:58PM +0000, Dino Klein wrote:
> I think you should look into initramfs / early-userspace, because I think 
> that's what it's intended for.
> Check the 2.6.1/Documentation/early-userspace directory.
> The files are unpacked pretty early, even before ACPI initialization. 
> That's what my patch and Markus Gaugusch's patch are based on, the fact 
> that initramfs/initrd are processed at such an early stage.
> 

Interressing.  Will take a look.

Thanks.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn