DSDT > 128k support

DSDT > 128k support

[Takayoshi Kochi]

Hi,

Under the current implementation, reading /proc/acpi/dsdt does

1. allocate enough buffer for the size of whole DSDT
2. copy real DSDT to the buffer
3. copy from the buffer to user-supplied pointer

Not only the two copies are redundant but also if DSDT > 128K,
1. will fail because internally it will use kmalloc to
allocate the buffer.

This patch tries to solve the problem by not allocating
the redundant buffer and copy directly to userspace.
(also does the same thing for /proc/acpi/fadt)

Tested with 2.6.10-rc2 on ia64 and i386.

My concern is that this patch uses an ACIPCA-internal function
(acpi_tb_get_table_ptr), but it's not so bad because scan.c already
does this;)

Len, please consider applying this.

---
Takayoshi Kochi


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: DSDT > 128k support

[Takayoshi Kochi]

Oops, forgot to attach the patch.

Signed-off-by: Takayoshi Kochi <t-kochi-UDFczIW9X1d8UrSeD/g0lQ@public.gmane.org>

---
Takayoshi Kochi

Index: 2.6.10-rc/drivers/acpi/system.c
===================================================================
--- 2.6.10-rc/drivers/acpi/system.c	(revision 58)
+++ 2.6.10-rc/drivers/acpi/system.c	(working copy)
@@ -27,6 +27,8 @@
 #include <linux/init.h>
 #include <asm/uaccess.h>
 
+#include <acpi/acpi.h>
+#include <acpi/actables.h>
 #include <acpi/acpi_drivers.h>
 
 
@@ -91,18 +93,17 @@
 	loff_t			*ppos)
 {
 	acpi_status		status = AE_OK;
-	struct acpi_buffer	dsdt = {ACPI_ALLOCATE_BUFFER, NULL};
+	struct acpi_table_header *tbl_ptr;
 	ssize_t			res;
 
 	ACPI_FUNCTION_TRACE("acpi_system_read_dsdt");
 
-	status = acpi_get_table(ACPI_TABLE_DSDT, 1, &dsdt);
+	status = acpi_tb_get_table_ptr(ACPI_TABLE_DSDT, 1, &tbl_ptr);
 	if (ACPI_FAILURE(status))
 		return_VALUE(-ENODEV);
 
 	res = simple_read_from_buffer(buffer, count, ppos,
-				      dsdt.pointer, dsdt.length);
-	acpi_os_free(dsdt.pointer);
+				      tbl_ptr, tbl_ptr->length);
 
 	return_VALUE(res);
 }
@@ -122,18 +123,17 @@
 	loff_t			*ppos)
 {
 	acpi_status		status = AE_OK;
-	struct acpi_buffer	fadt = {ACPI_ALLOCATE_BUFFER, NULL};
+	struct acpi_table_header *tbl_ptr;
 	ssize_t			res;
 
 	ACPI_FUNCTION_TRACE("acpi_system_read_fadt");
 
-	status = acpi_get_table(ACPI_TABLE_FADT, 1, &fadt);
+	status = acpi_tb_get_table_ptr(ACPI_TABLE_FADT, 1, &tbl_ptr);
 	if (ACPI_FAILURE(status))
 		return_VALUE(-ENODEV);
 
 	res = simple_read_from_buffer(buffer, count, ppos,
-				      fadt.pointer, fadt.length);
-	acpi_os_free(fadt.pointer);
+				      tbl_ptr, tbl_ptr->length);
 
 	return_VALUE(res);
 }


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: DSDT > 128k support

[Len Brown]

On Wed, 2004-11-17 at 09:08, Takayoshi Kochi wrote:

> Under the current implementation, reading /proc/acpi/dsdt does

I think the code in the kernel to supply /proc/acpi/dsdt
and /proc/acpi/fadt should be deleted.  This capability
and more can be had entirely from a user-space /dev/mem reader
such as acpidmp in the pmtools package:

http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/

-Len




-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Re: DSDT > 128k support

[Bjorn Helgaas]

On Wednesday 17 November 2004 10:51 am, Len Brown wrote:
> I think the code in the kernel to supply /proc/acpi/dsdt
> and /proc/acpi/fadt should be deleted.  This capability
> and more can be had entirely from a user-space /dev/mem reader
> such as acpidmp in the pmtools package:
> 
> http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/

Except that acpidmp still gropes through 0x000e0000-0x00100000
looking for something that looks like an RSDP.  I don't think
that works on ia64.  (We do provide /sys/firmware/efi/systab,
which contains the address you need, so acpidmp could probably
use that when it's available.)


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: Re: DSDT > 128k support

[Takayoshi Kochi]

> On Wednesday 17 November 2004 10:51 am, Len Brown wrote:
> > I think the code in the kernel to supply /proc/acpi/dsdt
> > and /proc/acpi/fadt should be deleted.  This capability
> > and more can be had entirely from a user-space /dev/mem reader
> > such as acpidmp in the pmtools package:
> > 
> > http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
> 
> Except that acpidmp still gropes through 0x000e0000-0x00100000
> looking for something that looks like an RSDP.  I don't think
> that works on ia64.  (We do provide /sys/firmware/efi/systab,
> which contains the address you need, so acpidmp could probably
> use that when it's available.)

Right, and pmtools doesn't seem to understand XSDT/GAS/64bit addresses
either, though it may not be so hard to add such support (but not me;).

Until pmtools or something equivalent supports ia64/x86_64,
could you apply the patch?

---
Takayoshi Kochi


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8