From: Alex Williamson <alex.williamson@hp.com>
To: Len Brown <len.brown@intel.com>
Cc: linux-ia64@vger.kernel.org,
acpi-devel <acpi-devel@lists.sourceforge.net>
Subject: Re: [ACPI] [PATCH] restore _OS object to "Linux" for ia64
Date: Mon, 13 Sep 2004 13:42:02 -0600 [thread overview]
Message-ID: <1095104522.20631.54.camel@tdi> (raw)
In-Reply-To: <1095103349.2512.16.camel@d845pe>
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
WARNING: multiple messages have this Message-ID (diff)
From: Alex Williamson <alex.williamson@hp.com>
To: Len Brown <len.brown@intel.com>
Cc: linux-ia64@vger.kernel.org,
acpi-devel <acpi-devel@lists.sourceforge.net>
Subject: Re: [ACPI] [PATCH] restore _OS object to "Linux" for ia64
Date: Mon, 13 Sep 2004 19:42:02 +0000 [thread overview]
Message-ID: <1095104522.20631.54.camel@tdi> (raw)
In-Reply-To: <1095103349.2512.16.camel@d845pe>
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
next prev parent reply other threads:[~2004-09-13 19:42 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-13 18:27 [PATCH] restore _OS object to "Linux" for ia64 Alex Williamson
2004-09-13 18:27 ` Alex Williamson
2004-09-13 19:22 ` Len Brown
2004-09-13 19:22 ` [ACPI] " Len Brown
2004-09-13 19:42 ` Alex Williamson [this message]
2004-09-13 19:42 ` Alex Williamson
-- strict thread matches above, loose matches on Subject: below --
2004-09-13 19:37 Moore, Robert
2004-09-13 19:37 ` Moore, Robert
2004-09-13 21:30 ` Gerald Pfeifer
2004-09-13 21:30 ` Gerald Pfeifer
2004-09-13 22:19 ` Nate Lawson
2004-09-13 22:19 ` Nate Lawson
2004-09-13 22:11 Moore, Robert
2004-09-13 22:11 ` [ACPI] " Moore, Robert
2004-09-13 22:59 Moore, Robert
2004-09-13 22:59 ` [ACPI] " Moore, Robert
2004-09-14 4:27 ` Alex Williamson
2004-09-14 4:27 ` Alex Williamson
2004-09-14 15:00 Moore, Robert
2004-09-14 15:00 ` Moore, Robert
2004-09-17 17:18 Moore, Robert
2004-09-17 17:18 ` Moore, Robert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1095104522.20631.54.camel@tdi \
--to=alex.williamson@hp.com \
--cc=acpi-devel@lists.sourceforge.net \
--cc=len.brown@intel.com \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.