[PATCH] restore _OS object to "Linux" for ia64

[PATCH] restore _OS object to "Linux" for ia64

[Alex Williamson]

   A recent change to ACPI made the _OS object falsely report the OS as
"Microsoft Windows NT".  This seems like a slippery slope, and I'd
rather not go down it for ia64.  I think all of the ia64 OEMs are
involved enough with Linux that this isn't necessary and the change
limits the options should ACPI firmware need to make an OS specific work
around.  The patch below will make all ia64 boxes report a default _OS
of "Linux".  Thanks,

	Alex

-- 
Signed-off-by: Alex Williamson <alex.williamson@hp.com>

===== arch/ia64/kernel/acpi.c 1.74 vs edited =====
--- 1.74/arch/ia64/kernel/acpi.c	Thu Aug  5 22:40:29 2004
+++ edited/arch/ia64/kernel/acpi.c	Mon Sep 13 09:32:46 2004
@@ -629,6 +629,13 @@
 #endif
 	/* Make boot-up look pretty */
 	printk(KERN_INFO "%d CPUs available, %d CPUs total\n", available_cpus, total_cpus);
+
+	/*
+	 * Make the _OS object report the right name, ia64 Linux has
+	 * enough OEM support that we shouldn't need to fake another OS.
+	 */
+	acpi_os_name_setup("Linux");
+
 	return 0;
 }
 
===== include/acpi/acpiosxf.h 1.34 vs edited =====
--- 1.34/include/acpi/acpiosxf.h	Fri Jul 16 23:37:53 2004
+++ edited/include/acpi/acpiosxf.h	Mon Sep 13 09:38:55 2004
@@ -313,6 +313,10 @@
 	u32                             function,
 	void                            *info);
 
+int __init
+acpi_os_name_setup (
+	char				*str);
+
 /*
  * Debug print routines
  */

Re: [PATCH] restore _OS object to "Linux" for ia64

[Len Brown]

On Mon, 2004-09-13 at 14:27, Alex Williamson wrote:
>    A recent change to ACPI made the _OS object falsely report the OS as
> "Microsoft Windows NT".  This seems like a slippery slope, and I'd
> rather not go down it for ia64.  I think all of the ia64 OEMs are
> involved enough with Linux that this isn't necessary and the change
> limits the options should ACPI firmware need to make an OS specific work
> around.  The patch below will make all ia64 boxes report a default _OS
> of "Linux".

While I share your pride in Linux, there are a couple of reasons
why we do not make _OS return "Linux".

_OS is a deprecated interface -- it has been replaced
by the more flexible _OSI.  So with _OS we're talking
about past, not future systems.  And there is a total
population of 0 systems in the installed base that check
for _OS ="Linux" in their firmware.  On the other hand, there
are zillions of systems that check for Windows with _OS,
and the !Windows path through the firmware is effectivly
unvalidated.

While this is really important on i386, it may not be
important for ia64.  However, unless you can show
me an existing system that checks for _OS=Linux, then
it only adds risk w/o reward to make this change, even
if just on ia64.  New systems should be using _OSI.

thanks,
-Len




-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: [ACPI] [PATCH] restore _OS object to "Linux" for ia64

[Alex Williamson]

On Mon, 2004-09-13 at 15:22 -0400, Len Brown wrote:
> On Mon, 2004-09-13 at 14:27, Alex Williamson wrote:
> >    A recent change to ACPI made the _OS object falsely report the OS as
> > "Microsoft Windows NT".  This seems like a slippery slope, and I'd
> > rather not go down it for ia64.  I think all of the ia64 OEMs are
> > involved enough with Linux that this isn't necessary and the change
> > limits the options should ACPI firmware need to make an OS specific work
> > around.  The patch below will make all ia64 boxes report a default _OS
> > of "Linux".
> 
> While I share your pride in Linux, there are a couple of reasons
> why we do not make _OS return "Linux".
> 
> _OS is a deprecated interface -- it has been replaced
> by the more flexible _OSI.  So with _OS we're talking
> about past, not future systems.  And there is a total
> population of 0 systems in the installed base that check
> for _OS ="Linux" in their firmware.  On the other hand, there
> are zillions of systems that check for Windows with _OS,
> and the !Windows path through the firmware is effectivly
> unvalidated.

  Perhaps true for i386.  While I don't know of any ia64 AML that checks
_OS, I do know that we extensively test any !Windows path that exists...
or at least we did.

> While this is really important on i386, it may not be
> important for ia64.  However, unless you can show
> me an existing system that checks for _OS=Linux, then
> it only adds risk w/o reward to make this change, even
> if just on ia64.  New systems should be using _OSI.

   I see the risk in *changing* the _OS, but not in leaving it the way
it was.  SLES9 has already shipped based on 2.6.5.  That ACPI CA set the
_OS to "Linux".  Many platforms have gone through full certification on
that kernel.  How is it more risky to stay with "Linux"?  If it's a
deprecated interface, why change it at the end of it's life when there
are no known benefits on ia64?  Thanks,

	Alex

-- 
Alex Williamson                             HP Linux & Open Source Lab

RE: [PATCH] restore _OS object to "Linux" for ia64

[Moore, Robert]

I don't know what the specific machines were.  There was lots of
discussion on the Linux/ACPI list before we did this.  I think they were
all 32-bit machines, however.


> -----Original Message-----
> From: Gerald Pfeifer [mailto:gp-l3A5Bk7waGM@public.gmane.org]
> Sent: Monday, September 13, 2004 2:30 PM
> To: Moore, Robert
> Cc: Brown, Len; Alex Williamson; linux-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ACPI
> Developers
> Subject: RE: [ACPI] [PATCH] restore _OS object to "Linux" for ia64
> 
> On Mon, 13 Sep 2004, Moore, Robert wrote:
> > Not only is the !Windows code path apparently untested for the most
> > part, we have discovered many machines that simply do not work
properly
> > unless we report "Microsoft Windows NT" for the _OS string.
> 
> Can you name some of these (broken) systems?
> 
> Given that we apparently did not encounter this with our 2.6.5-based
SLES9
> kernel so far, I'm a bit sceptical that many (if any) ia64 machines
are
> affected.
> 
> Gerald


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

RE: [PATCH] restore _OS object to "Linux" for ia64

[Moore, Robert]

Here's an example:

> -----Original Message-----
> From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:acpi-devel- 
> admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Martin Ginkel
> Sent: Wednesday, May 26, 2004 3:09 PM
> To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Cc: oysteigi-zs2scLodJVNRyvKAgBWctw@public.gmane.org
> Subject: Re: [ACPI] Wrong AC state
> 
> Martin Ginkel wrote:
> > On my laptop (Fujitsu-Siemens Amilo D 8830) this seems to be 
> > partially broken. The /proc/ac_adapter/AC0/state has a value on-line

> > or off-line from boot-time and doesn't change later on.
> 
> OK found a solution while reading the disassembled DSDT:
> The Code ist checking the OS-Version:
> 
>      Method (_PSR, 0, NotSerialized)
>      {
>        If (LNot (LEqual (FAKE, 0x00)))
>        {
>          Return (0x00)
>        }
>        Else
>        {
>          If (LOr (LEqual (OSFL (), 0x00), LEqual (OSFL (), 0x04)))
>            {
>               Store (\_SB.PCI0.SBRG.EC0.XCIN, Local0)
>                                      }
>           Else
>            {
>               Store (ACIN, Local0)
>            }
> 
>               Return (Local0)
>            }
>       }
> 
> 
> OSFL is returning 0x00 for win2000 and 0x04 for windows nt.
> I defined as a dirty fix:
> ./include/acpi/platform/aclinux.h:50:
> #define ACPI_OS_NAME               "Microsoft Windows NT"
> 
> Now the Power Monitor reacts instantly.
> 
> Well: the Bios seems to be designed for Microsoft Windows ;-P
> 
> 
> 	CU
> 	Martin
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 
> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. 
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
> https://lists.sourceforge.net/lists/listinfo/acpi-devel

> -----Original Message-----
> From: Moore, Robert
> Sent: Monday, September 13, 2004 3:11 PM
> To: 'Gerald Pfeifer'
> Cc: Brown, Len; Alex Williamson; linux-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ACPI
> Developers
> Subject: RE: [ACPI] [PATCH] restore _OS object to "Linux" for ia64
> 
> I don't know what the specific machines were.  There was lots of
> discussion on the Linux/ACPI list before we did this.  I think they
were
> all 32-bit machines, however.
> 
> 
> > -----Original Message-----
> > From: Gerald Pfeifer [mailto:gp-l3A5Bk7waGM@public.gmane.org]
> > Sent: Monday, September 13, 2004 2:30 PM
> > To: Moore, Robert
> > Cc: Brown, Len; Alex Williamson; linux-ia64-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ACPI
> > Developers
> > Subject: RE: [ACPI] [PATCH] restore _OS object to "Linux" for ia64
> >
> > On Mon, 13 Sep 2004, Moore, Robert wrote:
> > > Not only is the !Windows code path apparently untested for the
most
> > > part, we have discovered many machines that simply do not work
> properly
> > > unless we report "Microsoft Windows NT" for the _OS string.
> >
> > Can you name some of these (broken) systems?
> >
> > Given that we apparently did not encounter this with our 2.6.5-based
> SLES9
> > kernel so far, I'm a bit sceptical that many (if any) ia64 machines
are
> > affected.
> >
> > Gerald


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php