Markus Armbruster wrote:
> I didn't claim there's *no* difference between C89 and C99. In fact,
> the Rationale nicely documents the change:
>
> [snipped]
> Also, implementations that support an
> actual allocation when the size is zero do not necessarily return a
> null pointer f
Aborting without an error message when memory is short
is not helpful, so print the reason for the abort.
Try
qemu -m 100
or
qemu -m 2000 (win32)
to force an out-of-memory error.
v2:
* Fix error message for win32.
* Fix error message for posix_memalign.
Thanks to malc for th
This commit completes the do_pci_info() conversion to
QObject by adding support to PCI bridge devices.
This is done by recursively adding devices in the
"pci_bridge" key.
IMPORTANT: This code is being added separately because I could
NOT test it properly. According to Michael Tsirkin, it depends
The returned QObject is a QList of all buses. Each bus is
represented by a QDict, which has a key with a QList of all
PCI devices attached to it. Each device is represented by
a QDict.
As has happended to other complex conversions, it's hard to
split this commit as part of it are new functions whi
A helper to retrieve a QDict from a QDict.
Signed-off-by: Luiz Capitulino
---
qdict.c | 13 +
qdict.h |1 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/qdict.c b/qdict.c
index ba8eef0..c6a5a42 100644
--- a/qdict.c
+++ b/qdict.c
@@ -216,6 +216,19 @@ QList *qd
Iterate over QList entries, it's needed to call qlist_entry_obj()
to retrieve the stored QObject.
I'm not sure if it's ok to have this, because it's not as easy as
qlist_iter() and the QListEntry data type is now exposed to the
users, which means we have one more struct to be maintained when
we ha
Hi,
This new version fixes the printing of PCI bridge information,
as I was able to test it after some help from Blue Swirl.
Only the printing of PCI bridge attached devices remains
untested, but according to Blue Swirl attaching devices to it
is broken so I don't think it matters much.
chang
This is done by enforcing the following mode-oriented rules:
- QMP is started in handshake mode
- In handshake mode all protocol capabilities are disabled
and (apart of a few exceptions) only commands which
query/enable/disable them are allowed
- Asynchronous messages are now considered a capa
Signed-off-by: Luiz Capitulino
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 12dcc8f..526 100644
--- a/qerror.c
+++ b/qerror.c
@@ -109,6 +109,10 @@ static const QErrorStringTable qerror_table[] = {
Move the code used to locate an info command entry to its
own function, as it's going to be used by other functions.
Signed-off-by: Luiz Capitulino
---
monitor.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/monitor.c b/monitor.c
index 321bc3a..34d
This commit disables asynchronous messages by default and
introduces two new QMP commands: async_msg_enable and
async_msg_disable.
Each QMP Monitor has its own set of asynchronous messages,
so for example, if QEMU is run with two QMP Monitors async
messages setup in one of them doesn't affect the
Signed-off-by: Luiz Capitulino
---
qerror.c |4
qerror.h |3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 9dd729a..12dcc8f 100644
--- a/qerror.c
+++ b/qerror.c
@@ -41,6 +41,10 @@ static const QType qerror_type = {
*/
static const QEr
This commit moves the asynchronous messages names to an array
of structs, so that it can be indexed and searched.
Signed-off-by: Luiz Capitulino
---
monitor.c | 67 +++--
1 files changed, 34 insertions(+), 33 deletions(-)
diff --git a/mo
With feature negotiation support asynchronous messages are
going to behave like any protocol capability, that is, it
is disabled by default, it can be negotiated and has to be
advertised.
TODO: update spec.
Signed-off-by: Luiz Capitulino
---
monitor.c | 18 +-
1 files changed,
It will be used to switch between "handshake" and "operational"
modes. Currently it doesn't have any practical effect, as
mode-oriented support is not enforced yet.
Usage example:
{ "execute": "qmp_switch_mode", "arguments": { "mode": "operational" } }
Signed-off-by: Luiz Capitulino
---
monito
Two new errors:
- QERR_QMP_INVALID_MODE_NAME
- QERR_QMP_INVALID_MODE_TRANSACTION
Signed-off-by: Luiz Capitulino
---
qerror.c |8
qerror.h |6 ++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/qerror.c b/qerror.c
index 5f8fc5d..9dd729a 100644
--- a/qerror.c
Only valid in QMP and allowed to run in both "handshake" and
"operational" modes.
Signed-off-by: Luiz Capitulino
---
monitor.c | 42 ++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/monitor.c b/monitor.c
index 4b7067a..c475a38 100644
--
In order to support feature negotiation in QMP, the Monitor
has to be modified to support different modes of operation.
We need two modes:
o Handshake: where features are negotiated. Only commands
which deal with protocol configuration are allowed, async
messages (as any other protocol capability
Feature negotiation allows clients to enable QMP capabilities they are
interested in using. This allows QMP to envolve without breaking old clients.
A capability is a new QMP feature and/or protocol change which is not part of
the core protocol as defined in the QMP spec.
Feature negotiation i
On 01/21/2010 05:53 PM, Jamie Lokier wrote:
> If you make that IFS=${local_ifs:-$(printf ' \t\n')} it should be safe.
> Likewise if you set the value first.
Remove the colon. The above will wrongly change empty IFS, which
is not the same as unset IFS.
local_ifs would never be unset anyway,
On Thu, 21 Jan 2010, Markus Armbruster wrote:
> malc writes:
>
> > On Thu, 21 Jan 2010, Markus Armbruster wrote:
[..snip..]
> >> No, this is a misinterpretation of the C99 standard, made possible by
> >> its poor wording. The C99 Rationale is perfectly clear, though:
> >
> > You have to show
On 01/21/2010 10:43 AM, john cooper wrote:
Anthony Liguori wrote:
On 01/20/2010 07:18 PM, john cooper wrote:
I can appreciate the concern of wanting to get this
as "correct" as possible.
This is the root of the trouble. At the qemu layer, we try to focus on
being correct.
The default value is ${prefix}/etc/qemu. --confdir can be used to override the
default to an absolute path. The expectation is that when installed to /usr,
--confdir=/etc/qemu will be used.
Signed-off-by: Anthony Liguori
---
configure | 10 ++
1 files changed, 10 insertions(+), 0 de
Introduce a default option to the network device which specifies that this is
a default network device. This approach should generalize to any other device.
The meaning of a default device is as follows: a default device is added to a
machine IIF defaults aren't disable (via -default or -nodefaul
This option can be used to toggle whether each default device is enabled or
disabled. For character devices, the default backend can also be overridden.
For devices, we'll have to take a different approach to changing the defaults
which will be covered in the next patch.
N.B. I took special care
This series introduces global config files stored in /etc/qemu. There is both
a common config (qemu.conf) and a per-target config (target-.conf).
To demonstrate what can be done with global config, I've also made some
enhancements to the default device code that allows many of the builtin qemu
de
A new option, -nodefconfig is introduced to prevent loading from the default
config location. Otherwise, two configuration files will be searched for,
qemu.conf and target-.conf.
The ordering is a little troubling. Command line options are parsed before
loading the default configs which means th
malc writes:
> On Thu, 21 Jan 2010, Markus Armbruster wrote:
>
>> malc writes:
>>
>> > On Tue, 29 Dec 2009, Jamie Lokier wrote:
>> >
>> >> malc wrote:
>> >> > On Mon, 28 Dec 2009, Jamie Lokier wrote:
>> >> >
>> >> > > Aurelien Jarno wrote:
>> >> > > > This fixes the loading of a stripped kerne
Jamie Lokier writes:
> Markus Armbruster wrote:
>> malc writes:
>>
>> > On Tue, 29 Dec 2009, Jamie Lokier wrote:
>> >
>> >> malc wrote:
>> >> > On Mon, 28 Dec 2009, Jamie Lokier wrote:
>> >> >
>> >> > > Aurelien Jarno wrote:
>> >> > > > This fixes the loading of a stripped kernel with zero mal
Jamie Lokier wrote:
> I think we can all agree that there is no point looking for a familiar
> -cpu naming scheme because there aren't any familiar and meaningful names
> these days.
Even if we dismiss the Intel coined names as internal
code names, there is still VMW's use of them in this
space w
Jamie Lokier wrote:
> Do you mean that more powerful management tools to support safe
> migration will maintain _their own_ processor model tables, and
> perform their calculations using their own tables instead of querying
> qemu, and therefore not have any need of qemu's built in table?
I would
On Thu, 21 Jan 2010, Jamie Lokier wrote:
> Markus Armbruster wrote:
> > malc writes:
> >
> > > On Tue, 29 Dec 2009, Jamie Lokier wrote:
> > >
> > >> malc wrote:
> > >> > On Mon, 28 Dec 2009, Jamie Lokier wrote:
> > >> >
> > >> > > Aurelien Jarno wrote:
> > >> > > > This fixes the loading of a s
Markus Armbruster wrote:
> malc writes:
>
> > On Tue, 29 Dec 2009, Jamie Lokier wrote:
> >
> >> malc wrote:
> >> > On Mon, 28 Dec 2009, Jamie Lokier wrote:
> >> >
> >> > > Aurelien Jarno wrote:
> >> > > > This fixes the loading of a stripped kernel with zero malloc
> >> > > > disabled.
> >> > >
identifier scorpio schrieb:
> Thank Mr. Weil for your reply.
>
> >
> > Maybe you can also try the TCG interpreter (TCI) from
> > http://repo.or.cz/w/qemu/ar7.git.
> > In theory, it supports any host architecture with or
> > without native TCG
> > support.
> >
> > It was tested successful with som
john cooper wrote:
> I can appreciate the argument above, however the goal was
> choosing names with some basis in reality. These were
> recommended by our contacts within Intel, are used by VmWare
> to describe their similar cpu models, and arguably have fallen
> to defacto usage as evidenced by
On Thu, 21 Jan 2010, Markus Armbruster wrote:
> malc writes:
>
> > On Tue, 29 Dec 2009, Jamie Lokier wrote:
> >
> >> malc wrote:
> >> > On Mon, 28 Dec 2009, Jamie Lokier wrote:
> >> >
> >> > > Aurelien Jarno wrote:
> >> > > > This fixes the loading of a stripped kernel with zero malloc
> >> >
On 21 janv. 2010, at 16:24, Liran Schour wrote:
> Move to stage3 only when remaining work can be done below max downtime.
>
> Changes from v1: remove max iterations. Try to infer storage performance and
> by that calculate remaining work.
>
> Signed-off-by: Liran Schour
> ---
> block-migration
john cooper wrote:
> > I foresee wanting to iterate over the models and pick the latest one
> > which a host supports - on the grounds that you have done the hard
> > work of ensuring it is a reasonably good performer, while "probably"
> > working on another host of similar capability when a new ho
john cooper wrote:
> kvm itself can modify flags exported from qemu to a guest.
I would hope for an option to request that qemu doesn't run if the
guest won't get the cpuid flags requested on the command line.
-- Jamie
malc writes:
> On Tue, 29 Dec 2009, Jamie Lokier wrote:
>
>> malc wrote:
>> > On Mon, 28 Dec 2009, Jamie Lokier wrote:
>> >
>> > > Aurelien Jarno wrote:
>> > > > This fixes the loading of a stripped kernel with zero malloc disabled.
>> > >
>> > > *Raises an eyebrow*
>> > >
>> > > Even though t
On 01/21/10 17:44, Markus Armbruster wrote:
Markus Armbruster writes:
-fprintf(stderr, "property \"%s.%s\" not found\n",
-dev->info->name, name);
+fprintf(stderr, "%s.%s\n", dev->info->name, props->name);
+props++;
One quest
On Thu, Jan 21, 2010 at 2:39 PM, Andre Przywara wrote:
> john cooper wrote:
>>
>> Chris Wright wrote:
>>>
>>> * Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu ' are just as
unfriendly as each other. The only user friendly option is
On Thu, Jan 21, 2010 at 1:52 PM, Luiz Capitulino wrote:
> On Wed, 20 Jan 2010 19:22:48 +
> Blue Swirl wrote:
>
>> On Wed, Jan 20, 2010 at 6:11 PM, Luiz Capitulino
>> wrote:
>> > On Wed, 20 Jan 2010 18:57:56 +0100
>> > Markus Armbruster wrote:
>> >
>> >> Luiz Capitulino writes:
>> >>
>> >>
On 01/20/2010 10:15 PM, John Regehr wrote:
Hi folks-
Just wanted to let you know that perhaps the function
helper_neon_rshl_s8() is being miscompiled by the latest gcc.
I'm using qemu 0.12.2 and gcc rev 156103, which is a pre-version of gcc
4.5. This is on an x86 machine running Ubuntu 9.10.
A
Måns Rullgård wrote:
> If IFS is not set, the shell shall behave as if the value of IFS is
> , , and
>
> If you make that IFS=${local_ifs:-$(printf ' \t\n')} it should be safe.
> Likewise if you set the value first.
Remove the colon. The above will wrongly change empty IFS, which
is not the
Anthony Liguori wrote:
> On 01/20/2010 07:18 PM, john cooper wrote:
>> I can appreciate the concern of wanting to get this
>> as "correct" as possible.
>>
>
> This is the root of the trouble. At the qemu layer, we try to focus on
> being correct.
>
> Management tools are typically the layer
Stefan Weil writes:
> Markus Armbruster schrieb:
>> Stefan Weil writes:
>>
>>> Markus Armbruster schrieb:
[...]
While there, would you mind improving --help for -device a bit? It's
too terse, and it doesn't start the help text in column 16 like the
other options do.
>>> Hi Markus,
Markus Armbruster writes:
> Stefan Weil writes:
>
>> When called with property "?", a list of supported
>> properties will be printed (instead of an error message).
>>
>> This is useful for command lines like
>> qemu -device e1000,?
>> and was already standard for other options like model=?
Stefan Weil writes:
> When called with property value "?",
> a help text will be printed (instead of an error message).
>
> This is useful for command lines like
> qemu -device e1000,mac=?
> and is already standard for other command line options.
>
> A better help text could be provided by
Stefan Weil writes:
> When called with property "?", a list of supported
> properties will be printed (instead of an error message).
>
> This is useful for command lines like
> qemu -device e1000,?
> and was already standard for other options like model=?
>
> Signed-off-by: Stefan Weil
> -
Hi,
under a mostly stable Gentoo I observed this new msg :
tfoer...@n22 ~/virtual/kvm $ qemu -hda gentoo_kdevm.img -hdb
portage_kdeprefix.img -hdd swap.img -smp 2 -m 768 -vga std -soundhw es1370
BUG: kvm
Start transfer dirty blocks during the iterative stage. That will
reduce the time that the guest will be suspended
Changes from v1: remove trailing whitespaces and remove max iterations limit.
Signed-off-by: Liran Schour
---
block-migration.c | 135 +++--
Move to stage3 only when remaining work can be done below max downtime.
Changes from v1: remove max iterations. Try to infer storage performance and by
that calculate remaining work.
Signed-off-by: Liran Schour
---
block-migration.c | 136 +++--
This will manage dirty counter for each device and will allow to get the
dirty counter from above.
Changes from v1: remove trailing whitespaces.
Signed-off-by: Liran Schour
---
block.c | 16 ++--
block.h |1 +
block_int.h |1 +
3 files changed, 16 insertions(+), 2
blk_mig_save_bulked_block is never called with sync flag. Remove the sync
flag. Calculate bulk completion during blk_mig_save_bulked_block.
Changes from v1: remove trailing whitespaces and minor cleanups.
Signed-off-by: Liran Schour
---
block-migration.c | 59 +
This series of patches reduce the down time of the guest during a migration
without shared storage. It does that by start transfer dirty blocks in the
iterative phase. In the current code transferring of dirty blocks begins only
during the full phase while the guest is suspended. Therefore the gu
The n member is not very descriptive and very hard to grep, rename it to
cur_nr_sectors to better indicate what it is used for. Also rename
nb_sectors to remaining_sectors as that is what it is used for.
Signed-off-by: Christoph Hellwig
Index: qemu/block/qcow2.c
On 21.01.2010, at 15:19, Xiaodong Yi wrote:
> Luvalley is a lightweight type-1 Virtual Machine Monitor (VMM).
> Its part of source codes are derived from KVM to virtualize
> CPU instructions and memory management unit (MMU). However, its
> overall architecture is completely different from KVM, bu
On 01/20/2010 07:18 PM, john cooper wrote:
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a concise
Luiz Capitulino writes:
> On Thu, 21 Jan 2010 15:04:43 +0100
> Markus Armbruster wrote:
>
>> Luiz Capitulino writes:
>>
>> > On Wed, 20 Jan 2010 17:08:17 +0100
>> > Markus Armbruster wrote:
>> >
>> >> This is a double value with optional suffixes G, g, M, m, K, k. We'll
>> >> need this to ge
john cooper wrote:
Chris Wright wrote:
* Daniel P. Berrange (berra...@redhat.com) wrote:
To be honest all possible naming schemes for '-cpu ' are just as
unfriendly as each other. The only user friendly option is '-cpu host'.
IMHO, we should just pick a concise naming scheme & document it. G
On Thu, 21 Jan 2010 15:04:43 +0100
Markus Armbruster wrote:
> Luiz Capitulino writes:
>
> > On Wed, 20 Jan 2010 17:08:17 +0100
> > Markus Armbruster wrote:
> >
> >> This is a double value with optional suffixes G, g, M, m, K, k. We'll
> >> need this to get migrate_set_speed() QMP-ready.
> >
>
On Thu, 21 Jan 2010 14:54:51 +0100
Markus Armbruster wrote:
> Luiz Capitulino writes:
>
> > On Wed, 20 Jan 2010 17:08:20 +0100
> > Markus Armbruster wrote:
> >
> >> This is a double value with optional suffixes ms, us, ns. We'll need
> >> this to get migrate_set_downtime() QMP-ready.
> >>
>
Luvalley is a lightweight type-1 Virtual Machine Monitor (VMM).
Its part of source codes are derived from KVM to virtualize
CPU instructions and memory management unit (MMU). However, its
overall architecture is completely different from KVM, but somewhat
like Xen. Luvalley runs outside of Linux, j
Luiz Capitulino writes:
> On Wed, 20 Jan 2010 17:08:17 +0100
> Markus Armbruster wrote:
>
>> This is a double value with optional suffixes G, g, M, m, K, k. We'll
>> need this to get migrate_set_speed() QMP-ready.
>
> Nice, not only good for QMP: we're moving this kind of handling
> from the h
Luiz Capitulino writes:
> On Wed, 20 Jan 2010 17:08:20 +0100
> Markus Armbruster wrote:
>
>> This is a double value with optional suffixes ms, us, ns. We'll need
>> this to get migrate_set_downtime() QMP-ready.
>>
>> Signed-off-by: Markus Armbruster
>> ---
>> monitor.c | 16 +++
On Wed, 20 Jan 2010 19:22:48 +
Blue Swirl wrote:
> On Wed, Jan 20, 2010 at 6:11 PM, Luiz Capitulino
> wrote:
> > On Wed, 20 Jan 2010 18:57:56 +0100
> > Markus Armbruster wrote:
> >
> >> Luiz Capitulino writes:
> >>
> >> > Hi,
> >> >
> >> > This new version addresses Markus's comments.
>
Hi,
I don't know if this is already known. I found the ARM NEON vcvt instruction
mentioned in some fix in the mailing list archive, but not what has been
fixed.
However, I found a bug in the implementation of that instruction. I observe
that the type operands are emulated in the wrong order.
Exam
On Thu, Jan 21, 2010 at 03:19:28PM +0200, Naphtali Sprei wrote:
>
> >
> > - we now normally set the read_only flag from bdrv_open2 when we do
> >not have the O_RDWR flag set
> > - but the block drivers also mess with it:
> > o raw-posix superflously sets it when BDRV_O_RDWR is not in th
On Wed, 20 Jan 2010 17:08:20 +0100
Markus Armbruster wrote:
> This is a double value with optional suffixes ms, us, ns. We'll need
> this to get migrate_set_downtime() QMP-ready.
>
> Signed-off-by: Markus Armbruster
> ---
> monitor.c | 16 +++-
> 1 files changed, 15 insertions(+
Christoph Hellwig wrote:
> Looking at the version of this that landed in git I don't think the
> read-only handling is entirely clean after this.
I fixed what I could, still I got some questions below.
>
> - we now normally set the read_only flag from bdrv_open2 when we do
>not have the O_R
On Wed, 20 Jan 2010 17:08:17 +0100
Markus Armbruster wrote:
> This is a double value with optional suffixes G, g, M, m, K, k. We'll
> need this to get migrate_set_speed() QMP-ready.
Nice, not only good for QMP: we're moving this kind of handling
from the handlers to common code, which is the r
Signed-off-by: Naphtali Sprei
---
block/bochs.c |6 ++
block/parallels.c |6 ++
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/block/bochs.c b/block/bochs.c
index 3489258..fb83594 100644
--- a/block/bochs.c
+++ b/block/bochs.c
@@ -116,11 +116,9 @@ static int b
Found some places that seems needs this explicitly, now that
read-write is not the default.
Signed-off-by: Naphtali Sprei
---
block/qcow2.c |2 +-
block/vvfat.c |2 +-
qemu-img.c|4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
Found some places that seems needs this explicitly, now that
read-write is not the default.
Signed-off-by: Naphtali Sprei
---
block/qcow2.c |2 +-
block/vvfat.c |2 +-
qemu-img.c|4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/block/qcow2.c b/block/qcow2.c
Signed-off-by: Naphtali Sprei
---
block.c |7 ---
block.h |1 -
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/block.c b/block.c
index 73c26ec..8378c18 100644
--- a/block.c
+++ b/block.c
@@ -1009,13 +1009,6 @@ int bdrv_is_read_only(BlockDriverState *bs)
return bs
Signed-off-by: Naphtali Sprei
---
block.c |7 ---
block.h |1 -
2 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/block.c b/block.c
index 73c26ec..8378c18 100644
--- a/block.c
+++ b/block.c
@@ -1009,13 +1009,6 @@ int bdrv_is_read_only(BlockDriverState *bs)
return bs
*** BLURB HERE ***
Naphtali Sprei (3):
No need anymore for bdrv_set_read_only
Ask for read-write permissions when opening files where needed
Read-only device changed to opens it's file for read-only.
block.c |7 ---
block.h |1 -
block/bochs.c |6 ++-
*** BLURB HERE ***
Naphtali Sprei (3):
No need anymoe for bdrv_set_read_only
Ask for read-write permissions when opening files
Read-only device changed to opens it's file for read-only.
block.c |7 ---
block.h |1 -
block/bochs.c |6 ++
block/par
A comment from Christoph Hellwig made me check (and fix) some stuff.
I'm afraid there are some more callers that needs to explicitly ask for
read-write permissions.
I'd like to get comments about that.
P.S. The qcow2 bug (I introduced) in pre-allocate showed me there's a need to
check return val
Juan Quintela writes:
> Loïc Minier wrote:
>> On Wed, Jan 20, 2010, Måns Rullgård wrote:
>>> If you make that IFS=${local_ifs:-$(printf ' \t\n')} it should be safe.
>>> Likewise if you set the value first.
>>
>> Ok; see attached patches
>
> I still think that path_of is a complication that we d
On (Wed) Jan 13 2010 [12:32:54], Amit Shah wrote:
> >
> > I'd be very interested in the results of Sparc32 and Sparc64 analyses.
>
> OK, I added the two targets to the run and got the following result:
>
> http://amitshah.fedorapeople.org/clang-output/2010-01-13-1/
>
> The bug count went up fro
These hunks got dropped off mysteriously during the rebasing of my
virtio-serial series. Thanks go to Markus for noticing it.
Without these fixes, -virtioconsole doesn't actually have any effect.
Signed-off-by: Amit Shah
Reported-by: Markus Armbruster
---
roms/seabios |2 +-
vl.c |
This file was renamed to ease the reviews of the recent changes
that went in.
Now that the changes are done, rename the file back to its original
name.
Signed-off-by: Amit Shah
---
Makefile.objs|2 +-
hw/{virtio-serial.c => virtio-console.c} |0
2 files chang
On (Thu) Jan 21 2010 [10:53:36], Markus Armbruster wrote:
> Amit, what about renaming hw/virtio-serial.c to a less misleading name
> now?
I'm going to push that upstream; Anthony in the past indicated he was ok
with it.
Amit
Amit, what about renaming hw/virtio-serial.c to a less misleading name
now?
Loïc Minier wrote:
> On Wed, Jan 20, 2010, Måns Rullgård wrote:
>> If you make that IFS=${local_ifs:-$(printf ' \t\n')} it should be safe.
>> Likewise if you set the value first.
>
> Ok; see attached patches
I still think that path_of is a complication that we don't really need.
"type" command
Juan Quintela writes:
> Gleb Natapov wrote:
>> On Wed, Jan 20, 2010 at 09:14:03PM +0100, Juan Quintela wrote:
[...]
>>> diff --git a/block/vvfat.c b/block/vvfat.c
>>> index 063f731..df957e5 100644
>>> --- a/block/vvfat.c
>>> +++ b/block/vvfat.c
>>> @@ -868,7 +868,8 @@ static int init_directories
On Wed, Jan 20, 2010, Måns Rullgård wrote:
> If you make that IFS=${local_ifs:-$(printf ' \t\n')} it should be safe.
> Likewise if you set the value first.
Ok; see attached patches
--
Loïc Minier
>From cccdcaeacc2214390c0c6c198ed875ac59d10669 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=2
On Thu, Jan 21, 2010 at 09:17:27AM +0100, Juan Quintela wrote:
> Gleb Natapov wrote:
> > On Wed, Jan 20, 2010 at 09:14:03PM +0100, Juan Quintela wrote:
> >> From: Kirill A. Shutemov
> >>
> >> CCblock/vvfat.o
> >> cc1: warnings being treated as errors
> >> block/vvfat.c: In function 'commit_o
Gleb Natapov wrote:
> On Wed, Jan 20, 2010 at 09:14:03PM +0100, Juan Quintela wrote:
>> From: Kirill A. Shutemov
>>
>> CCblock/vvfat.o
>> cc1: warnings being treated as errors
>> block/vvfat.c: In function 'commit_one_file':
>> block/vvfat.c:2259: error: ignoring return value of 'ftruncate',
91 matches
Mail list logo
