At 11/03/2011 09:36 AM, Kevin O'Connor Write:
On Thu, Nov 03, 2011 at 09:04:57AM +0800, Wen Congyang wrote:
At 11/03/2011 08:30 AM, Kevin O'Connor Write:
I think it's reasonable to require that a user supplied DSDT still fill certain requirements. Keep in mind that the reason for the "user supplied" DSDT was for new platform (q35) development - not necessarily so each individual user could set their own.
I do not think it's reasonable to require that a user supplied DSDT still fill certain requiements.
Please elaborate on why.
If we require it, I think it is very bad designed, because the user should read seabios before he writes DSDT. I think the user should only need to know how to pass his DSDT and SSDT to seabios. He should be able to write his DSDT and SSDT without knowing seabios's DSDT and SSDT.
Another problem is that: if we require it, but the user does not do it, I do not know the behavior. According to ACPI, SSDT can only add data, and can not overwrite the data. So the user must know the data in SSDT. If we update SSDT, and add new data that may exist in user supplied DSDT, the behavior is undefined.
So I think we should not use default SSDT when we use user supplied DSDT. If so, the user can write his DSDT easier.
The dependency on the DSDT is a few methods (PCEJ, CPEJ, CPST, CPMA). Under what circumstances would it be difficult for these methods to be provided?
I think we should not use default SSDT if we use user supplied DSDT. If we use user supplied DSDT, we should use user supplied SSDT too.
That's possible. However, how do you plan to provide a DSDT that accounts for the dynamic nature of the virtual system configuration. A different qemu/kvm command line (which configures pci or cpu count) will then require a different DSDT.
Hmm, I do not think it now. I think DSDT and SSDT can be generated in qemu, but it is very complex.
I have another question: is seabios used only by qemu now? Or it is a common bios, and is not only for qemu?
Thanks Wen Congyang
-Kevin