DSDT in initrd

DSDT in initrd

[Michael Frank]

Hi All,

I would like to use the DSDT override and have at this time at 3 buggy DSDT's to fix.

So far I build a modular kernel for use on all machines, even those w/o ACPI.

IMHO this patch is very useful because it provides the equivalent of a "DSDT module" and avoids building a kernel for each DSDT.

Please consider inclusion.


Regards
Michael


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

RE: DSDT in initrd

[Brown, Len]

> IMHO this patch is very useful because it provides the 
> equivalent of a "DSDT module" and avoids building a kernel 
> for each DSDT.

This is the 1st reason I've seen for not simply using an ACPI_DSDT_OVERRIDE
config option to pull a DSDT into the kernel from a well-known file name.

I figure that the set of people who go to the trouble to get a custom DSDT
are mostly included in the set of people who config and build a kernel for
their system.  As such, ACPI_DSDT_OVERRIDE would be simple and sufficient --
without requiring admins to change any code.

It makes me uneasy to append the DSDT to the initrd image.  This encumbers
the initrd booting scheme with ACPI BIOS workarounds.  What happens when
somebody changes how initrd works?  If appending a DSDT image to initrd is
okay, why not append other things such as the ACPI black-list, for the same
reasons?

I think I'd be happier with the DSDT being _in_ the initrd as a named
file/module -- just like the other boot-time modules, rather than being
magically appended to the image.  Of course this would require you to run
mkinitrd for each platform; unless multiple named tables were included in
the initrd.

-Len


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

RE: DSDT in initrd

[Markus Gaugusch]

On May 15, Brown, Len <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:

> It makes me uneasy to append the DSDT to the initrd image.  This encumbers
> the initrd booting scheme with ACPI BIOS workarounds.  What happens when
> somebody changes how initrd works?
It's like everything in the kernel: If something changes and breaks
something else, the other things will be fixed as well, or the change will
be reverted. (or in the worst case, the other things will be removed).

> If appending a DSDT image to initrd is okay, why not append other things
> such as the ACPI black-list, for the same reasons?
The DSDT is one of the most dynamic things for ACPI hackers. If there is
the need to put other things into the initrd: no problem. The existing
patch should cooperate with bootsplash and should do so as well with other
'magic attachments'.

> I think I'd be happier with the DSDT being _in_ the initrd as a named
> file/module -- just like the other boot-time modules, rather than being
> magically appended to the image.
I'll try to find out if it is possible in any way. I think that filesystem
drivers are not available at this stage of booting (why should they? they
are not needed and it would probably be a big and ugly hack to load them
in such an early stage.)

> Of course this would require you to run mkinitrd for each platform;
> unless multiple named tables were included in the initrd.
That's the least problem.

Markus
-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

Re: DSDT in initrd

[Michael Frank]

On Friday 16 May 2003 09:41, Brown, Len wrote:
> > IMHO this patch is very useful because it provides the
> > equivalent of a "DSDT module" and avoids building a kernel
> > for each DSDT.
>
> This is the 1st reason I've seen for not simply using an
> ACPI_DSDT_OVERRIDE config option to pull a DSDT into the kernel
> from a well-known file name.

DSDT problems will be around for a long time as this technology makes it into the main stream, while still maturing.

For example: I found DSDT of a recent P4 mainboard has 16 compile errors. 

Realistically, one can't go really into production with it without being able to override.

>
> I figure that the set of people who go to the trouble to get a
> custom DSDT are mostly included in the set of people who config and
> build a kernel for their system.  As such, ACPI_DSDT_OVERRIDE would
> be simple and sufficient -- without requiring admins to change any
> code

A fixed override at build time was OK during the development phase.

However, this is totally impractical in a production environment. It's simply not maintainable.

A modular DSDT has further benefits:

  - Given the quality of the current DSDT 
    tools, it may encourage more  testing 
    and fixing of DSDTs

  - Distribution installers eventualy 
    could handle the selection and 
    installation of a DSDT

>
> It makes me uneasy to append the DSDT to the initrd image.  This
> encumbers the initrd booting scheme with ACPI BIOS workarounds. 
> What happens when somebody changes how initrd works?  If appending
> a DSDT image to initrd is okay, 

Touching a standard is good cause for concern, but the magnitude of 
change is relatively small and transparent to the enduser.

Emphasizing "modular", we can look at this patch as incremental progress helping ACPI into a production environment.

This patch should be selectable by a seperate config option.

> why not append other things such as
> the ACPI black-list, for the same reasons?

Deserves further consideration as port of continued evolution of the ACPI subsystem. 

>
> I think I'd be happier with the DSDT being _in_ the initrd as a
> named file/module -- just like the other boot-time modules, rather
> than being magically appended to the image.  Of course this would
> require you to run mkinitrd for each platform; unless multiple
> named tables were included in the initrd.
>

Which IMHO is better, more flexible, "standard" and should be the next step

One might consider a means of selecting DSDT's using the blacklist and put all into initrd.....


Regards
Michael

 



-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

RE: DSDT in initrd

[Grover, Andrew]

> From: Michael Frank [mailto:mflt1-DTdK3Ks6N5kHTnRCetW4+N0b+6lKrnBL@public.gmane.org] 
> On Friday 16 May 2003 09:41, Brown, Len wrote:
> > > IMHO this patch is very useful because it provides the
> > > equivalent of a "DSDT module" and avoids building a kernel
> > > for each DSDT.
> >
> > This is the 1st reason I've seen for not simply using an
> > ACPI_DSDT_OVERRIDE config option to pull a DSDT into the kernel
> > from a well-known file name.
> 
> DSDT problems will be around for a long time as this 
> technology makes it into the main stream, while still maturing.
> 
> For example: I found DSDT of a recent P4 mainboard has 16 
> compile errors. 
> 
> Realistically, one can't go really into production with it 
> without being able to override.

It should be obvious that using DSDT override (however easy we make it)
is NOT an option for distributions or any sort of non-developer
solution. You mention that distributions could install DSDTs on
installation but I don't buy it. This is part of the reason that I
haven't been very receptive towards making DSDT override very easy.

We need to look for solutions that make using an ACPI-enabled kernel
possible on the widest number of machines possible, *without* involving
DSDT override. If there are bugs in the interpreter, we need to fix
them. If there are bugs in the DSDT, we need to get on OEMs to fix them.
Or, we need to have a blacklist that, either via specific system
signatures or just BIOS date, safely reverts to non-ACPI on machines on
which it has problems.

I really think it's kind of funny that so many people on this mailing
list have gotten so good at fixing their systems' DSDT (maybe they
should apply for BIOS engineer jobs!) but this skill is the equivalent
of requiring someone to know how an engine works in order to drive a
car.

Regards -- Andy


-------------------------------------------------------
This SF.net email is sponsored by: 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

Re: DSDT in initrd

[Randy.Dunlap]

On Fri, 16 May 2003 15:50:40 -0700 "Grover, Andrew" <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:

| > From: Michael Frank [mailto:mflt1-DTdK3Ks6N5kHTnRCetW4+N0b+6lKrnBL@public.gmane.org] 
| > On Friday 16 May 2003 09:41, Brown, Len wrote:
| > > > IMHO this patch is very useful because it provides the
| > > > equivalent of a "DSDT module" and avoids building a kernel
| > > > for each DSDT.
| > >
| > > This is the 1st reason I've seen for not simply using an
| > > ACPI_DSDT_OVERRIDE config option to pull a DSDT into the kernel
| > > from a well-known file name.
| > 
| > DSDT problems will be around for a long time as this 
| > technology makes it into the main stream, while still maturing.
| > 
| > For example: I found DSDT of a recent P4 mainboard has 16 
| > compile errors. 
| > 
| > Realistically, one can't go really into production with it 
| > without being able to override.
| 
| It should be obvious that using DSDT override (however easy we make it)
| is NOT an option for distributions or any sort of non-developer
| solution. You mention that distributions could install DSDTs on
| installation but I don't buy it. This is part of the reason that I
| haven't been very receptive towards making DSDT override very easy.
| 
| We need to look for solutions that make using an ACPI-enabled kernel
| possible on the widest number of machines possible, *without* involving
| DSDT override. If there are bugs in the interpreter, we need to fix
| them. If there are bugs in the DSDT, we need to get on OEMs to fix them.
| Or, we need to have a blacklist that, either via specific system
| signatures or just BIOS date, safely reverts to non-ACPI on machines on
| which it has problems.
| 
| I really think it's kind of funny that so many people on this mailing
| list have gotten so good at fixing their systems' DSDT (maybe they
| should apply for BIOS engineer jobs!) but this skill is the equivalent
| of requiring someone to know how an engine works in order to drive a
| car.

Well I kinda like this patch, but then I'm not a normal Linux user.  :)

Lots of newer systems don't have an option of "... safely reverts to
non-ACPI ...", and surely you know that.  It's make ACPI work in some
fashion or have no power management.

It seems that your goal is idealistic and not user-friendly, at least
not in the short-term.  It's a worthy long-term goal.

The ACPI interpreter will always have bugs in it.  The BIOS DSDTs
will always have bugs.  After all, they are software (or firmware).

--
~Randy


-------------------------------------------------------
This SF.net email is sponsored by: 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

RE: DSDT in initrd

[Grover, Andrew]

> From: Randy.Dunlap [mailto:rddunlap-3NddpPZAyC0@public.gmane.org] 
> Lots of newer systems don't have an option of "... safely reverts to
> non-ACPI ...", and surely you know that.  It's make ACPI work in some
> fashion or have no power management.

Yeah but DSDT in initrd doesn't help solve the problem for anyone but
hackers.

> It seems that your goal is idealistic and not user-friendly, at least
> not in the short-term.  It's a worthy long-term goal.

Anything that does not use the DSDT from the BIOS is not user-friendly.
It should "just work" for as many people as possible, without hackery.
It's never going to be 100%. The only way I can think of to get close is
if we take the time to implement a cutoff based on BIOS date, with both
a Good and Bad BIOS list, for exceptions to that cutoff.

I must admit I'm really torn. If there were 2-3 little AML problems that
if we worked around them, a horde of machines would start working, then
I think we would do that, but my sense is that there are many more ways
a DSDT can be broken, and that implementing workarounds for all of them
would cause other systems to fail. Maybe some of the people who have
fixed their DSDTs can comment on the scope of bugs out there.

> The ACPI interpreter will always have bugs in it.  The BIOS DSDTs
> will always have bugs.  After all, they are software (or firmware).

All I can say w.r.t. bugs is that it used to be the case that when
diagnosing an issue, I started with the assumption the BIOS was right
and the interpreter had a bug -- now I start with the assumption that
the BIOS is buggy. :) If we can come up with a solution to mitigate the
impact of bad DSDTs, then in my mind the only things left are 1)
squashing the few bugs left in the PCI IRQ routing code and 2) sleep
support. We've come a long way baby!

Regards -- Andy


-------------------------------------------------------
This SF.net email is sponsored by: 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

RE: DSDT in initrd

[Markus Gaugusch]

On May 16, Grover, Andrew <andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:

> It should be obvious that using DSDT override (however easy we make it)
> is NOT an option for distributions or any sort of non-developer
> solution. You mention that distributions could install DSDTs on
> installation but I don't buy it. This is part of the reason that I
> haven't been very receptive towards making DSDT override very easy.
I think that no distribution will deliver fixed DSDT's, but people can
download them from acpi.sf.net, or ask people here to fix them.
More and more people are using distribution kernels, and it is hard for
them to compile their own. If we can implement an easy solution to solve
severe problems (and a broken DSDT is something that WILL lead to severe
problems in many cases), we should do it.

> We need to look for solutions that make using an ACPI-enabled kernel
> possible on the widest number of machines possible, *without* involving
> DSDT override.
Of course we should do this, but this doesn't mean that there should not
be alternatives.

> If there are bugs in the DSDT, we need to get on OEMs to fix them.
As I said, I fixed the DSDT four year old compaq laptop a few weeks ago,
to get battery status and other things that a user expects to get from a
laptop. No vendor will provide updates for machines being that old.

> Or, we need to have a blacklist that, either via specific system
> signatures or just BIOS date, safely reverts to non-ACPI on machines on
> which it has problems.
ACPI has many benefits, and linux users usually like to get the last out
of their machines. There are old machines supporting ACPI, and we should
support them, even if the default DSDT is broken.

> I really think it's kind of funny that so many people on this mailing
> list have gotten so good at fixing their systems' DSDT (maybe they
> should apply for BIOS engineer jobs!) but this skill is the equivalent
> of requiring someone to know how an engine works in order to drive a
> car.
Many people with old (or sometimes even new!) cars have to go to an
engineer to get it fixed.  Sometimes even for free, if you have good
friends :)

Markus
-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
This SF.net email is sponsored by: 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

Re: DSDT in initrd

[Mark Santcroos]

General question from a FreeBSD'er...

Do the vendors also use the iASL compiler or do they have their one tools?

Mark

-- 
Mark Santcroos                    RIPE Network Coordination Centre
http://www.ripe.net/home/mark/    New Projects Group/TTM


-------------------------------------------------------
This SF.net email is sponsored by: 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

RE: DSDT in initrd

[Adachi, Kenichi]

Hi,

> General question from a FreeBSD'er...
> 
> Do the vendors also use the iASL compiler or do they have 
> their one tools?

Take a look at Creater ID of original tables.
Likely MSFT is still most common.

Thanks,
- Adachi, Kenichi



-------------------------------------------------------
This SF.net email is sponsored by: 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

RE: DSDT in initrd

[Brown, Len]

I agree with Andy that the OSDs should avoid the DSDT distribution and
support business.  It is the OEM's job to ship a working BIOS, and they will
do so if they want to pass the OSD's certification test suite.

The concept of a DSDT override is a workaround -- fine for bringup,
development, hackers, enthusiasts, wizards etc.  But somebody who pays money
for a production box that runs Linux will buy one that the OSD certifies and
supports.

So unless the Linux community wants to slide down the slippery slope of
running any old broken BIOS -- forever -- we should maintain -- indeed
sharpen -- our ability to reject bad firmware -- and generously apply that
ability when the OEM goes before an OSD for certification.

Cheers,
-Len


-------------------------------------------------------
This SF.net email is sponsored by: 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

Re: DSDT in initrd

[Ducrot Bruno]

On Mon, May 19, 2003 at 07:38:21AM -0700, Brown, Len wrote:
> I agree with Andy that the OSDs should avoid the DSDT distribution and
> support business.  It is the OEM's job to ship a working BIOS, and they will
> do so if they want to pass the OSD's certification test suite.
> 
> The concept of a DSDT override is a workaround -- fine for bringup,
> development, hackers, enthusiasts, wizards etc.  But somebody who pays money
> for a production box that runs Linux will buy one that the OSD certifies and
> supports.
> 
> So unless the Linux community wants to slide down the slippery slope of
> running any old broken BIOS -- forever -- we should maintain -- indeed
> sharpen -- our ability to reject bad firmware -- and generously apply that
> ability when the OEM goes before an OSD for certification.
> 

Most trouble come with laptops, not servers (almost all servers
that I have tested work without any real troubles for now).

BUT there is indeed a need to provide workarounds for
_laptops_ users.

-- 
Ducrot Bruno

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


-------------------------------------------------------
This SF.net email is sponsored by: 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

Re: DSDT in initrd

[Michael Frank]

On Monday 19 May 2003 22:38, Brown, Len wrote:
> I agree with Andy that the OSDs should avoid the DSDT distribution
> and support business.  It is the OEM's job to ship a working BIOS,
> and they will do so if they want to pass the OSD's certification
> test suite.

I agree with this too.

>
> The concept of a DSDT override is a workaround -- fine for bringup,
> development, hackers, enthusiasts, wizards etc.  But somebody who
> pays money for a production box that runs Linux will buy one that
> the OSD certifies and supports.

OK, so can we put that patch in as a config option for the benefit of the "fine" listed above? 

>
> So unless the Linux community wants to slide down the slippery
> slope of running any old broken BIOS -- forever -- we should
> maintain -- indeed sharpen -- our ability to reject bad firmware --
> and generously apply that ability when the OEM goes before an OSD
> for certification.
>

Just visited osdl.org. Where to find info on hw certification. Any list of compliant hw available?


Regards
Michael




-------------------------------------------------------
This SF.net email is sponsored by: 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

Re: DSDT in initrd

[Christian Zoz]

On Fri, May 16, Grover, Andrew wrote:
> 
> It should be obvious that using DSDT override (however easy we make it)
> is NOT an option for distributions or any sort of non-developer
> solution. You mention that distributions could install DSDTs on
> installation but I don't buy it. This is part of the reason that I
> haven't been very receptive towards making DSDT override very easy.

Distributors cannot ship fixed DSDTs. That would be to much work. But
there are a lot of Linux Newbies with a laptop that worked so far with
W*. Now they are going to try Linux and get ACPI troubles.
It's far easier to explain them to place a fixed DSDT in a certain
file and to call mkinitrd than to guide them trough a kernel
complilation and installation.
Life would be ways easier for supporters. 

There are people wich benefit from this patch.
Does this patch harm on the other side?

> We need to look for solutions that make using an ACPI-enabled kernel
> possible on the widest number of machines possible, *without* involving
> DSDT override. If there are bugs in the interpreter, we need to fix
> them.

Yes.

> If there are bugs in the DSDT, we need to get on OEMs to fix them.

Yes.

> Or, we need to have a blacklist that, either via specific system
> signatures or just BIOS date, safely reverts to non-ACPI on machines on
> which it has problems.

You cannot always revert to non-ACPI without losing funcionality.

At this point the average private laptop user is left alone. Why don't
we help him to fix his buggy DSDT?

> I really think it's kind of funny that so many people on this mailing
> list have gotten so good at fixing their systems' DSDT (maybe they
> should apply for BIOS engineer jobs!)

Wonderfull! This maybe helps to come to more sophisticated BIOS
engineer and thus better BIOSs. ;)))

> but this skill is the equivalent of requiring someone to know how an
> engine works in order to drive a car.

Sometimes i were glad i could fix the programming of my bordcomputer
myself.

-- 

ciao, christian

  --------------------------------------------------------------------
    Verglichen mit jedem x-beliebigen Redmonder Betriebssystem-Clone
    ist Linux geradezu eine leuchtende Perle der Datensicherheit.
  ------ Frank Rennemann (http://www.linux-knowledge-portal.org) -----


-------------------------------------------------------
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

RE: DSDT in initrd

[Markus Gaugusch]

On May 19, Brown, Len <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:

> The concept of a DSDT override is a workaround -- fine for bringup,
> development, hackers, enthusiasts, wizards etc.  But somebody who pays
> money for a production box that runs Linux will buy one that the OSD
> certifies and supports.
Isn't linux the OS that runs on nearly EVERY hardware? Although there is a
lot of power behind the linux movement, we should not become arrogant.
We can't force the industry to support old machines (sometimes not even
new ones).

> So unless the Linux community wants to slide down the slippery slope of
> running any old broken BIOS -- forever -- we should maintain -- indeed
> sharpen -- our ability to reject bad firmware -- and generously apply that
> ability when the OEM goes before an OSD for certification.
Certification is usually expensive (at least one has to do it, I am not
even talking about paying for it). I am NOT always in the position where I
can choose the hardware, and many other people as well.

My patch is configurable (can be turned off via menuconfig), so please
apply it and do us hackers a favor.

kind regards
Markus


--- linux.orig/drivers/acpi/osl.c	2003-05-09 20:08:34.000000000 +0200
+++ linux/drivers/acpi/osl.c	2003-05-09 20:16:37.000000000 +0200
@@ -36,6 +36,8 @@
 #include <asm/io.h>
 #include <acpi/acpi_bus.h>
 #include <acpi/acpi.h>
+#include <linux/init.h>
+#include <linux/vmalloc.h>

 #ifdef CONFIG_ACPI_EFI
 #include <linux/efi.h>
@@ -222,14 +224,59 @@
 	return AE_OK;
 }

+
+#ifdef CONFIG_ACPI_INITRD
+unsigned char* get_dsdt_from_initrd(unsigned char *start, unsigned char *end)
+{
+	unsigned char *data;
+	unsigned char signature[] = "INITRDDSDT123DSDT123";
+
+	if (start == NULL)
+		return NULL;
+	printk(KERN_INFO "Looking for DSDT in initrd ...");
+	if (!memcmp(start, "DSDT", 4)) {
+		printk(" found at beginning!\n");
+		return start;
+	}
+	end-=sizeof(signature)+5; /* don't scan above end, signature+\0+DSDT */
+	for (data=start; data < end ; ++data) {
+		if (!memcmp(data, signature, sizeof(signature)-1)) {
+			if (!memcmp(data+sizeof(signature), "DSDT", 4)) {
+				printk(" found (at offset %u)!\n", data+sizeof(signature)-start);
+				return data+sizeof(signature);
+			}
+		}
+	}
+	printk(" not found!\n");
+
+	return NULL;
+}
+#endif
+
+
 acpi_status
 acpi_os_table_override (struct acpi_table_header *existing_table,
 			struct acpi_table_header **new_table)
 {
+#ifdef CONFIG_ACPI_INITRD
+	extern unsigned long initrd_start, initrd_end;
+	unsigned char* new_dsdt=NULL;
+
+#endif
 	if (!existing_table || !new_table)
 		return AE_BAD_PARAMETER;

+#ifdef CONFIG_ACPI_INITRD
+	if (strncmp(existing_table->signature, "DSDT", 4) == 0 &&
+		(new_dsdt=get_dsdt_from_initrd((unsigned char*)initrd_start,
+			(unsigned char*)initrd_end)) != NULL)
+		*new_table = (struct acpi_table_header*)new_dsdt;
+	else
+		*new_table = NULL;
+#else
 	*new_table = NULL;
+#endif
+
 	return AE_OK;
 }

--- linux.orig/drivers/acpi/Config.in	2003-05-05 18:44:41.000000000 +0200
+++ linux/drivers/acpi/Config.in	2003-05-05 20:19:06.000000000 +0200
@@ -12,6 +12,10 @@
       bool         'CPU Enumeration Only' CONFIG_ACPI_HT_ONLY
     fi

+    if [ "$CONFIG_BLK_DEV_INITRD" = "y" ]; then
+      bool         'Read DSDT from initrd' CONFIG_ACPI_INITRD
+    fi
+
     if [ "$CONFIG_ACPI_HT_ONLY" = "y" ]; then
       define_bool CONFIG_ACPI_BOOT		y
     else
--- linux.orig/Documentation/Configure.help	2003-05-05 19:51:09.000000000 +0200
+++ linux/Documentation/Configure.help	2003-05-05 20:18:56.000000000 +0200
@@ -18602,6 +18602,14 @@
   handles PnP messages.  All ACPI devices use its services, so using
   them requires saying Y here.

+ACPI DSDT in initrd
+CONFIG_ACPI_INITRD
+	The DSDT (Differentiated System Description Table) often needs to be
+	overridden because of broken BIOS implementations. If you want to use
+	a customized DSDT, just copy it to /boot/initrd (which must be used as
+  initrd, of course). See http://gaugusch.at/kernel.shtml for instructions
+  on using an existing initrd with ACPI. If unsure, say N here.
+
 ACPI System Driver
 CONFIG_ACPI_SYS
   This driver will enable your system to shut down using ACPI, and

-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
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

Re: DSDT in initrd

[Matthew Wilcox]

On Tue, May 20, 2003 at 06:56:59PM +0200, Markus Gaugusch wrote:
> My patch is configurable (can be turned off via menuconfig), so please
> apply it and do us hackers a favor.

No.  Linus will take one look at it and vomit.  It'll harm the chances of
getting ACPI into 2.4 (which is really necessary).  I disagree that this
should be applied to the main tree, but it should be fairly prominently
linked on http://acpi.sourceforge.net/

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk


-------------------------------------------------------
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

Re: DSDT in initrd

[Markus Gaugusch]

On May 20, Matthew Wilcox <willy-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> 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.

Markus
-- 
__________________    /"\
Markus Gaugusch       \ /    ASCII Ribbon Campaign
markus-z+rTbpWsRgbk7+2FdBfRIA@public.gmane.org     X     Against HTML Mail
                      / \


-------------------------------------------------------
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

Re: DSDT in initrd

[Nathan Gray]

Markus Gaugusch wrote:

> On May 20, Matthew Wilcox <willy-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
> 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