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
Hi all,
I m new to this site.. I have query on kernel based virtualisation..
I have backported kvm module of linux version 2.6.25 to linux 2.6.21.. Compilation is fine now but while insertion of kvm module is failing..
When i print dmesg i m getting like this..
"BUG: at lib/kobject.c: 176 kobject_shadow_add()"
Its returning some in WARN_ON() condition.. May i knw why it is happening like this..
Larsen & Toubro Infotech Ltd. www.Lntinfotech.com
This Document is classified as:
L&T Infotech Proprietary L&T Infotech Confidential L&T Infotech Internal Use Only L&T Infotech General Business
This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.
______________________________________________________________________