RE: DSDT in initrd

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

[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

Re: Re: DSDT in initrd

[Gunter Ohrner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Mittwoch, 21. Mai 2003 09:23 schrieb Nathan Gray:
> > 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.

I cannot. It needs help from the boot loader.

> 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

There is, but at the time the DSDT is needed the filesystem drivers probably 
are not yet initialized so you cannot use them to access the DSDT.

Greetings,

  Gunter

- -- 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                   PGP-verschlüsselte Mails bevorzugt!                 +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Lady Ramkin's bosom rose and fell like an empire.        -- (Terry 
Pratchett, Guards! Guards!)
+-+-+-+-+-+-+-+-+-+-+-+-+ http://www.lspace.org +-+-+-+-+-+-+-+-+-+-+-+-+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+yzPQ0ORHvREo8l8RAneNAJ97y4L7ni+1gMmLIlh+NMrkxHkY7gCeN4oc
+SAL4tHxCxs6v+Bqn/7rdE0=
=FHC6
-----END PGP SIGNATURE-----



-------------------------------------------------------
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: Re: DSDT in initrd

[Markus Gaugusch]

On May 21, Nathan Gray <n8gray-7GExONQZ6ZKVc3sceRu5cw@public.gmane.org> wrote:

> 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.
The file is not loaded by the kernel, but by the boot loader. Someone said
that grub is able to load more than one file, but I think lilo is not.
Also, the kernel has only support for one initrd, and I am not good enough
at the moment to add support for more, I guess.
Although the way I use to read the initrd is a bit hacker-ish, it is not
that bad I think. Bootsplash uses the same technique and is used by major
distributors. If it were insecure they could not use it (initrd is a major
part for distributions with pre-compiled kernels).

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: Re: DSDT in initrd

[Richard Black]

Concerning Red Hat Linux, the initrd.img is a compressed ext2 filesystem 
and the ext2 driver is built statically into the kernel.

The question is if ext2 is built statically into the kernel then are the 
ext2 functions (i.e. the ext2 driver) available when ACPI would be 
trying to load the dsdt table. My first response would be yes, since it 
is static in the kernel, you may use those functions any time you need 
them -- but that's only a guess as I haven't studied how the kernel 
boots that closely.

If anyone wants to examine initrd.img files it is super simple -- make 
use of the command "file" to help you along on your own. Or if you want 
full details then I have them here: http://www.cpqlinux.com/rhdiskmod.html

Probably the splash is just raw data attached to the initrd because it 
is likely it needs to be used before the kernel is even loaded. In our 
case the kernel is in the process of loading or is loaded.

Sincerely,
Richard Black

Markus Gaugusch wrote:

>On May 21, Nathan Gray <n8gray-7GExONQZ6ZKVc3sceRu5cw@public.gmane.org> wrote:
>
>  
>
>>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.
>>    
>>
>The file is not loaded by the kernel, but by the boot loader. Someone said
>that grub is able to load more than one file, but I think lilo is not.
>Also, the kernel has only support for one initrd, and I am not good enough
>at the moment to add support for more, I guess.
>Although the way I use to read the initrd is a bit hacker-ish, it is not
>that bad I think. Bootsplash uses the same technique and is used by major
>distributors. If it were insecure they could not use it (initrd is a major
>part for distributions with pre-compiled kernels).
>
>Markus
>  
>




-------------------------------------------------------
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: Re: DSDT in initrd

[Ducrot Bruno]

On Wed, May 21, 2003 at 10:05:47AM -0500, Richard Black wrote:
> Concerning Red Hat Linux, the initrd.img is a compressed ext2 filesystem 
> and the ext2 driver is built statically into the kernel.
> 
> The question is if ext2 is built statically into the kernel then are the 
> ext2 functions (i.e. the ext2 driver) available when ACPI would be 
> trying to load the dsdt table. My first response would be yes, since it 
> is static in the kernel, you may use those functions any time you need 
> them -- but that's only a guess as I haven't studied how the kernel 
> boots that closely.

No.  acpi is initialized too early (due to irq routing stuff for example)
VFS is intialized way to late to be used for retrieving acpi tables in
disks.

If you want something like that, you have to modify boot loaders (grub,lilo,
etc.) then write approriate code in kernel setup stage, etc.  It is 
actually not so hard to do.  Just, well, boring stuff in fact, not to
mention you have to send patch to at least main boot loaders maintainers.

-- 
Ducrot Bruno

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


-------------------------------------------------------
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: Re: DSDT in initrd

[Nathan Gray]

Markus Gaugusch wrote:

> On May 21, Nathan Gray <n8gray-7GExONQZ6ZKVc3sceRu5cw@public.gmane.org>
> wrote:
> 
>> 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.
> The file is not loaded by the kernel, but by the boot loader. Someone said
> that grub is able to load more than one file, but I think lilo is not.

That's what I imagined.  I didn't mean to attribute this to the kernel, but
I see that's basically how I wrote it.

> Also, the kernel has only support for one initrd, and I am not good enough
> at the moment to add support for more, I guess.

I know it's not easy, but if it's the right way then it's the right way.

> Although the way I use to read the initrd is a bit hacker-ish, it is not
> that bad I think. Bootsplash uses the same technique and is used by major
> distributors. If it were insecure they could not use it (initrd is a major
> part for distributions with pre-compiled kernels).

I don't think anybody's questioning the security of the approach.  I just
get the feeling that you'll get resistance to it.  You might try floating
the idea on the kernel list and see how people react.  I've got my opinion
on how it should work, but I can see that you have to have this data very
early on and it will not be trivial to make it work my way.  Linus may end
up agreeing with you, which would probably help your argument for inclusion
of your patch.  :-)

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