[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090711220211.GA1670@ucw.cz>
Date: Sun, 12 Jul 2009 00:02:11 +0200
From: Pavel Machek <pavel@....cz>
To: Len Brown <lenb@...nel.org>
Cc: Matthew Garrett <mjg59@...f.ucam.org>,
sfi-devel@...plefirmware.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC/PATCH 2.6.32] Simple Firmware Interface (SFI): initial
support
On Wed 2009-06-24 17:13:18, Len Brown wrote:
> On Mon, 22 Jun 2009, Pavel Machek wrote:
>
> > On Tue 2009-06-23 14:41:28, Len Brown wrote:
>
> > > Please let me know if your questions are not thoroughly answered here:
> > > http://simplefirmware.org/faq
> >
> > It really tells us nothing. I don't think flash got so expensive that
> > this is justified. ACPI can already do the job, right? and operating
> > systems already have to support ACPI. So what are the reasons to
> > reinvent the wheel?
>
> The price of flash, and the amount consumed, is not relevent
> to the decision whether a platform should support SFI or ACPI.
>
> 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.
>
> Yes, the ACPI specification could have been edited to replace
> every "must" with "could", "shall" with "may", and "required" with
> "optional" resulting in "ACPI compliance" for your toaster.
> But doing so would have been a dis-service to the
> platforms supporting ACPI, and would have made the
> already hard job of supporting ACPI from the OS significantly harder.
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.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists