On 01/28/2015 09:56 AM, Michael S. Tsirkin wrote:
I've tried redo series with passing alloc list as first argument,
looks ugly as hell
I tried too. Not too bad at all. See below:
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index f66da5d..820504a 100644
--- a/hw/i386/acpi-build.c
On 01/28/2015 12:29 AM, Igor Mammedov wrote:
On Mon, 26 Jan 2015 18:17:55 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Jan 26, 2015 at 04:34:01PM +0100, Andrew Jones wrote:
On Mon, Jan 26, 2015 at 04:09:20PM +0100, Igor Mammedov wrote:
On Mon, 26 Jan 2015 10:57:21 +0100
Igor
On 01/28/2015 12:00 PM, Igor Mammedov wrote:
On Wed, 28 Jan 2015 09:56:26 +0200
[...]
Hence is suggesting at least to hide AmlPool internally in API
without exposing it to user. We can provide for user
init/free API to manage internal AmlPool manually, allowing
him to select when to do
On Thu, 29 Jan 2015 15:46:32 +0800
Shannon Zhao zhaoshengl...@huawei.com wrote:
On 2015/1/28 18:00, Igor Mammedov wrote:
On Wed, 28 Jan 2015 09:56:26 +0200
Michael S. Tsirkin m...@redhat.com wrote:
I've tried redo series with passing alloc list as first argument,
looks ugly as hell
On Wed, Jan 28, 2015 at 09:56:26AM +0200, Michael S. Tsirkin wrote:
I've tried redo series with passing alloc list as first argument,
looks ugly as hell
I tried too. Not too bad at all. See below:
I'm not so sure. Looking at the version below, I find the
acpi_arg1(p) the most distracting.
On Wed, Jan 28, 2015 at 11:50:14AM +0100, Igor Mammedov wrote:
On Wed, 28 Jan 2015 12:24:23 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jan 28, 2015 at 11:00:23AM +0100, Igor Mammedov wrote:
On Wed, 28 Jan 2015 09:56:26 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, 28 Jan 2015 09:56:26 +0200
Michael S. Tsirkin m...@redhat.com wrote:
I've tried redo series with passing alloc list as first argument,
looks ugly as hell
I tried too. Not too bad at all. See below:
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index f66da5d..820504a
Hello Igor,
It's quite difficult to understand all the different options, there have been
quite a few flying around.
I'll comment this mail in particular, ignoring for the moment all the other
exchanges
(about QOM etc).
On 28.01.2015 11:00, Igor Mammedov wrote:
On Wed, 28 Jan 2015 09:56:26
On Wed, 28 Jan 2015 12:24:23 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Jan 28, 2015 at 11:00:23AM +0100, Igor Mammedov wrote:
On Wed, 28 Jan 2015 09:56:26 +0200
Michael S. Tsirkin m...@redhat.com wrote:
I've tried redo series with passing alloc list as first argument,
On Wed, Jan 28, 2015 at 11:00:23AM +0100, Igor Mammedov wrote:
On Wed, 28 Jan 2015 09:56:26 +0200
Michael S. Tsirkin m...@redhat.com wrote:
I've tried redo series with passing alloc list as first argument,
looks ugly as hell
I tried too. Not too bad at all. See below:
diff
On 2015/1/28 18:00, Igor Mammedov wrote:
On Wed, 28 Jan 2015 09:56:26 +0200
Michael S. Tsirkin m...@redhat.com wrote:
I've tried redo series with passing alloc list as first argument,
looks ugly as hell
I tried too. Not too bad at all. See below:
diff --git a/hw/i386/acpi-build.c
On Mon, 26 Jan 2015 18:17:55 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Jan 26, 2015 at 04:34:01PM +0100, Andrew Jones wrote:
On Mon, Jan 26, 2015 at 04:09:20PM +0100, Igor Mammedov wrote:
On Mon, 26 Jan 2015 10:57:21 +0100
Igor Mammedov imamm...@redhat.com wrote:
On
I've tried redo series with passing alloc list as first argument,
looks ugly as hell
I tried too. Not too bad at all. See below:
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index f66da5d..820504a 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -491,14 +491,14 @@
On Tue, Jan 27, 2015 at 11:29:09PM +0100, Igor Mammedov wrote:
On Mon, 26 Jan 2015 18:17:55 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Mon, Jan 26, 2015 at 04:34:01PM +0100, Andrew Jones wrote:
On Mon, Jan 26, 2015 at 04:09:20PM +0100, Igor Mammedov wrote:
On Mon, 26 Jan 2015
On Mon, Jan 26, 2015 at 04:09:20PM +0100, Igor Mammedov wrote:
On Mon, 26 Jan 2015 10:57:21 +0100
Igor Mammedov imamm...@redhat.com wrote:
On Sat, 24 Jan 2015 18:33:50 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Fri, Jan 23, 2015 at 06:56:20PM +0100, Igor Mammedov wrote:
On Mon, 26 Jan 2015 10:57:21 +0100
Igor Mammedov imamm...@redhat.com wrote:
On Sat, 24 Jan 2015 18:33:50 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Fri, Jan 23, 2015 at 06:56:20PM +0100, Igor Mammedov wrote:
On Fri, 23 Jan 2015 15:55:11 +0200
Michael S. Tsirkin m...@redhat.com
On Mon, Jan 26, 2015 at 04:34:01PM +0100, Andrew Jones wrote:
On Mon, Jan 26, 2015 at 04:09:20PM +0100, Igor Mammedov wrote:
On Mon, 26 Jan 2015 10:57:21 +0100
Igor Mammedov imamm...@redhat.com wrote:
On Sat, 24 Jan 2015 18:33:50 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Sat, 24 Jan 2015 18:33:50 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Fri, Jan 23, 2015 at 06:56:20PM +0100, Igor Mammedov wrote:
On Fri, 23 Jan 2015 15:55:11 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Fri, Jan 23, 2015 at 02:40:30PM +0100, Igor Mammedov wrote:
On
v.s. explicit headache of alloc/free, which doesn't fix
use-after-free anyway and just adds more boiler plate
plus makes code har to read read
str = aml_alloc();
aml_string(str, foo);
loc0 = aml_alloc();
aml_local(loc0, 0);
store = aml_alloc();
aml_store(store,
On Fri, Jan 23, 2015 at 06:56:20PM +0100, Igor Mammedov wrote:
On Fri, 23 Jan 2015 15:55:11 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Fri, Jan 23, 2015 at 02:40:30PM +0100, Igor Mammedov wrote:
On Fri, 23 Jan 2015 15:24:24 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Fri, 23 Jan 2015 15:55:11 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Fri, Jan 23, 2015 at 02:40:30PM +0100, Igor Mammedov wrote:
On Fri, 23 Jan 2015 15:24:24 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Fri, Jan 23, 2015 at 11:35:29AM +0100, Igor Mammedov wrote:
On
On Fri, 23 Jan 2015 15:24:24 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Fri, Jan 23, 2015 at 11:35:29AM +0100, Igor Mammedov wrote:
On Fri, 23 Jan 2015 10:11:19 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jan 22, 2015 at 02:49:45PM +, Igor Mammedov wrote:
On Fri, Jan 23, 2015 at 02:40:30PM +0100, Igor Mammedov wrote:
On Fri, 23 Jan 2015 15:24:24 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Fri, Jan 23, 2015 at 11:35:29AM +0100, Igor Mammedov wrote:
On Fri, 23 Jan 2015 10:11:19 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jan 22, 2015 at 02:49:45PM +, Igor Mammedov wrote:
Adds for dynamic AML creation, which will be used
for piecing ASL/AML primitives together and hiding
from user/caller details about how nested context
should be closed/packed leaving less space for
mistakes and necessity to know
On Thu, Jan 22, 2015 at 02:49:45PM +, Igor Mammedov wrote:
Adds for dynamic AML creation, which will be used
for piecing ASL/AML primitives together and hiding
from user/caller details about how nested context
should be closed/packed leaving less space for
mistakes and necessity to know
On Thu, Jan 22, 2015 at 02:49:45PM +, Igor Mammedov wrote:
Adds for dynamic AML creation, which will be used
for piecing ASL/AML primitives together and hiding
from user/caller details about how nested context
should be closed/packed leaving less space for
mistakes and necessity to know
On Fri, 23 Jan 2015 10:03:03 +0200
Michael S. Tsirkin m...@redhat.com wrote:
+typedef enum {
+NON_BLOCK,
+PACKAGE,
+EXT_PACKAGE,
+BUFFER,
+RES_TEMPLATE,
+} AcpiBlockFlags;
Please prefix values with ACPI_BUILD_ - don't pollute the
global namespace.
Could we
On Fri, 23 Jan 2015 10:11:19 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jan 22, 2015 at 02:49:45PM +, Igor Mammedov wrote:
Adds for dynamic AML creation, which will be used
for piecing ASL/AML primitives together and hiding
from user/caller details about how nested context
On Fri, Jan 23, 2015 at 11:35:29AM +0100, Igor Mammedov wrote:
On Fri, 23 Jan 2015 10:11:19 +0200
Michael S. Tsirkin m...@redhat.com wrote:
On Thu, Jan 22, 2015 at 02:49:45PM +, Igor Mammedov wrote:
Adds for dynamic AML creation, which will be used
for piecing ASL/AML primitives
On Fri, Jan 23, 2015 at 11:03:54AM +0100, Igor Mammedov wrote:
On Fri, 23 Jan 2015 10:03:03 +0200
Michael S. Tsirkin m...@redhat.com wrote:
+typedef enum {
+NON_BLOCK,
+PACKAGE,
+EXT_PACKAGE,
+BUFFER,
+RES_TEMPLATE,
+} AcpiBlockFlags;
Please prefix
Adds for dynamic AML creation, which will be used
for piecing ASL/AML primitives together and hiding
from user/caller details about how nested context
should be closed/packed leaving less space for
mistakes and necessity to know how AML should be
encoded, allowing user to concentrate on ASL
31 matches
Mail list logo
