From: Peter Stuge <peter@stuge.se>
To: Pavel Machek <pavel@ucw.cz>
Cc: Len Brown <lenb@kernel.org>,
sfi-devel@simplefirmware.org, linux-kernel@vger.kernel.org,
coreboot@coreboot.org
Subject: Re: [SFI-devel] [RFC/PATCH 2.6.32] Simple Firmware Interface (SFI): initial support
Date: Mon, 13 Jul 2009 05:25:59 +0200 [thread overview]
Message-ID: <20090713032559.23220.qmail@stuge.se> (raw)
In-Reply-To: <20090711220211.GA1670@ucw.cz>
Hi Pavel,
Pavel Machek wrote:
> > > ACPI can already do the job, right?
As Len explains, it can't.
> > > and operating systems already have to support ACPI.
I disagree here. How so? There are certainly other ways to accomplish
what ACPI does.
> > > So what are the reasons to reinvent the wheel?
Hardware developments push firmware and operating systems to new
places. I believe that's both neccessary and normal.
> > The Moorestown platform doesn't use ACPI because its chip-set
> > fundamentally does not support it. Not only is the required
> > register set missing, *all* IO accesses are missing, and there is
> > no SMM support present to emuate it.
..
> Well, you should have just selected subset of ACPI, documenting that
> and implementing that. You would not have 'acpi compliant' logo, and
> windows XP would not boot on that, but at least you would not have
> created one more bios standard for people to support.
I don't think that's a practical option though.
I've been involved in the coreboot (formerly LinuxBIOS) project for a
good number of years, in part because I realized that the PC firmware
environment had lacked any serious developments for a very long time
and anything new, especially open source, was a good idea.
There's a certain stigma to coreboot in parts of the Linux kernel
community, because it's something very new and different in the x86
firmware landscape. Let me just say that I completely understand the
desire to resist changes in what is a somewhat functioning and at any
rate very wide spread technology. It seems that SFI is now facing
some of the same resistance, for much the same reason.
x86 architecture is changing, and firmware must change with it. It
will do operating systems good to join in, early on. Ideally there
will be much more cooperation across disciplines than in the past,
especially since hardware and software are already converging to a
point where good engineers on either side really must know also how
the other camp works. The only thing that remains with x86 is the
instruction set, every other part of the architecture has changed, is
changing, and will continue to change. That affects both firmware and
operating system of course.
ACPI is not always ideal, some may argue never. SFI strikes me as a
good complement. I think we will come to see further alternatives,
and finally I think that's a good thing, as software and hardware
continues to develop.
Of course it's not simple for operating systems. Nor for firmware.
But I don't believe the optimal and practical solution is to resist
rounder and lighter wheels.
//Peter
next prev parent reply other threads:[~2009-07-13 3:32 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-23 7:13 Len Brown
2009-06-23 7:13 ` [PATCH 1/8] SFI: Simple Firmware Interface - new Linux sub-system Len Brown
2009-06-23 7:14 ` [PATCH 2/8] SFI: include/linux/sfi.h Len Brown
2009-06-23 7:28 ` Ingo Molnar
2009-06-23 7:47 ` Feng Tang
2009-06-23 8:00 ` Ingo Molnar
2009-06-23 8:02 ` Feng Tang
2009-06-23 8:09 ` Ingo Molnar
2009-06-23 15:14 ` H. Peter Anvin
2009-06-30 21:57 ` Andrew Morton
2009-06-30 21:59 ` Ingo Molnar
2009-06-23 9:06 ` Sam Ravnborg
2009-06-23 15:52 ` Feng Tang
2009-06-23 19:26 ` Sam Ravnborg
2009-06-23 7:14 ` [PATCH 3/8] SFI: core support Len Brown
2009-06-23 7:56 ` Ingo Molnar
2009-06-23 8:32 ` Feng Tang
2009-06-23 9:03 ` Ingo Molnar
2009-06-23 9:15 ` Feng Tang
2009-06-23 17:20 ` Len Brown
2009-06-23 19:20 ` Ingo Molnar
2009-06-23 12:32 ` Andi Kleen
2009-06-23 16:57 ` Len Brown
2009-06-24 3:34 ` Feng Tang
2009-06-24 7:12 ` Andi Kleen
2009-06-24 7:40 ` Feng Tang
2009-06-24 7:55 ` Andi Kleen
2009-06-23 7:14 ` [PATCH 4/8] SFI: Hook boot-time initialization Len Brown
2009-06-23 7:14 ` [PATCH 5/8] SFI: Hook e820 memory map initialization Len Brown
2009-06-23 7:14 ` [PATCH 6/8] SFI: add ACPI extensions Len Brown
2009-06-23 12:18 ` Andi Kleen
2009-06-23 16:51 ` Len Brown
2009-06-23 7:14 ` [PATCH 7/8] SFI, PCI: Hook MMCONFIG Len Brown
2009-06-23 7:14 ` [PATCH 8/8] SFI: expose IO-APIC routines to SFI, not just ACPI Len Brown
2009-06-23 7:58 ` Ingo Molnar
2009-06-23 7:23 ` [PATCH 1/8] SFI: Simple Firmware Interface - new Linux sub-system Ingo Molnar
2009-06-23 18:31 ` [RFC/PATCH 2.6.32] Simple Firmware Interface (SFI): initial support Matthew Garrett
2009-06-23 18:41 ` Len Brown
2009-06-22 19:43 ` Pavel Machek
2009-06-24 21:13 ` Len Brown
2009-07-11 22:02 ` Pavel Machek
2009-07-13 3:25 ` Peter Stuge [this message]
2009-06-23 18:51 ` Matthew Garrett
2009-06-23 20:00 ` Len Brown
2009-06-23 20:23 ` Matthew Garrett
2009-06-23 20:45 ` Matthew Garrett
2009-06-23 21:23 ` Alan Cox
2009-06-23 22:34 ` Len Brown
2009-06-23 22:20 ` Len Brown
2009-06-23 22:56 ` Matthew Garrett
2009-06-23 23:00 ` [SFI-devel] " Justen, Jordan L
2009-06-24 0:35 ` Len Brown
2009-06-23 21:33 ` Len Brown
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=20090713032559.23220.qmail@stuge.se \
--to=peter@stuge.se \
--cc=coreboot@coreboot.org \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=sfi-devel@simplefirmware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®