Hi Yongbok Kim,
On 03/10/2017 08:58 AM, Yongbok Kim wrote:
> On 10/03/2017 11:53, Thomas Huth wrote:
>> On 10.03.2017 12:22, Peter Maydell wrote:
>>> On 10 March 2017 at 12:07, Jason Wang wrote:
On 2017年03月09日 18:20, Yongbok Kim wrote:
> Indeed but we still use the platform to verify arc
You can have two floppy drives, but they are hooked to the same
Yes, I'm aware.
I'm just saying here "Spec-wise" because you can have two controllers,
one at 0x3F0 and one at 0x370.
Oh, ok. Wasn't aware of this detail.
Can't remember to have ever seen a pc with more than two floppy drives
(
Hi,
> > You can have two floppy drives, but they are hooked to the same
>
> Yes, I'm aware.
>
> I'm just saying here "Spec-wise" because you can have two controllers,
> one at 0x3F0 and one at 0x370.
Oh, ok. Wasn't aware of this detail.
Can't remember to have ever seen a pc with more than t
On 04/19/2017 06:15 AM, Gerd Hoffmann wrote:
> Hi,
>
>>> There is -global, which is actually used by libvirt to configure
>>> built-in floppy devices. But as the name suggests it sets properties
>>> globally, i.e. for all instances. Which works in this specific use
>>> case, as there can be
Hi,
> >> We probably want something like
> >> -qom-set-property {objpath|alias}.prop=value
>
> Makes sense to me.
>
> We should be able to desugar -net, ... to -qom-set-property then.
> However, the desugaring would be machine-specific in general.
Yes. Establishing rules for alias names fo
Hi,
> > There is -global, which is actually used by libvirt to configure
> > built-in floppy devices. But as the name suggests it sets properties
> > globally, i.e. for all instances. Which works in this specific use
> > case, as there can be only one floppy controller per machine, but I
>
>
John Snow writes:
> On 04/18/2017 07:57 AM, Gerd Hoffmann wrote:
>> Hi,
>>
Just like -device is a general way to plug in devices, replacing
multiple special ways (-net, -drive, -usb, ...), we could use a general
way to configure onboard devices.
>>>
>>> I looked at the -device i
On 04/18/2017 07:57 AM, Gerd Hoffmann wrote:
> Hi,
>
>>> Just like -device is a general way to plug in devices, replacing
>>> multiple special ways (-net, -drive, -usb, ...), we could use a general
>>> way to configure onboard devices.
>>
>> I looked at the -device implementation to see if the
Hi,
> > Just like -device is a general way to plug in devices, replacing
> > multiple special ways (-net, -drive, -usb, ...), we could use a general
> > way to configure onboard devices.
>
> I looked at the -device implementation to see if the bus= parameter
> could be used to specify onboard d
On Tue, Apr 11, 2017 at 02:53:00PM +0200, Markus Armbruster wrote:
> Stefan Hajnoczi writes:
>
> > On Mon, Mar 27, 2017 at 01:49:44PM +0100, Peter Maydell wrote:
> >> On 27 March 2017 at 13:01, Stefan Hajnoczi wrote:
> >> > It would be nice to get rid of the legacy -net option in 3.0.0. I have
Hi,
> What about deprecating GTK 2.0 ? SDL (1.2 or all?)
gtk2 + sdl1 makes sense.
sdl2 proably has too many users to drop it. Not everybody prefers the
gtk ui ...
cheers,
Gerd
Hi
On Wed, Mar 8, 2017 at 12:20 PM Gerd Hoffmann wrote:
> Hi,
>
> > libvirt suffered similar lack of clarity around when to bump major
> version
> > number as opposed to minor version. To address this we recently adopted
> the
> > rule[1] that major version number changes have no relation to f
Stefan Hajnoczi writes:
> On Mon, Mar 27, 2017 at 01:49:44PM +0100, Peter Maydell wrote:
>> On 27 March 2017 at 13:01, Stefan Hajnoczi wrote:
>> > It would be nice to get rid of the legacy -net option in 3.0.0. I have
>> > added it and included pointers to loose ends. I think this is doable
>>
On Mon, Mar 27, 2017 at 01:49:44PM +0100, Peter Maydell wrote:
> On 27 March 2017 at 13:01, Stefan Hajnoczi wrote:
> > It would be nice to get rid of the legacy -net option in 3.0.0. I have
> > added it and included pointers to loose ends. I think this is doable
> > but will require some time to
On 27.03.2017 21:04, John Snow wrote:
>
>
> On 03/27/2017 04:06 AM, Thomas Huth wrote:
>> On 24.03.2017 23:10, John Snow wrote:
>>>
>>>
>>> On 03/08/2017 03:26 AM, Thomas Huth wrote:
Hi everybody,
what will be the next version of QEMU after 2.9? Will we go for a 2.10
(as
On 03/27/2017 04:06 AM, Thomas Huth wrote:
> On 24.03.2017 23:10, John Snow wrote:
>>
>>
>> On 03/08/2017 03:26 AM, Thomas Huth wrote:
>>>
>>> Hi everybody,
>>>
>>> what will be the next version of QEMU after 2.9? Will we go for a 2.10
>>> (as I've seen it mentioned a couple of times on the mail
On 27 March 2017 at 13:01, Stefan Hajnoczi wrote:
> It would be nice to get rid of the legacy -net option in 3.0.0. I have
> added it and included pointers to loose ends. I think this is doable
> but will require some time to achieve.
What's the syntax for using -netdev with embedded network
de
On Mon, Mar 27, 2017 at 10:06:09AM +0200, Thomas Huth wrote:
> On 24.03.2017 23:10, John Snow wrote:
> >
> >
> > On 03/08/2017 03:26 AM, Thomas Huth wrote:
> >>
> >> Hi everybody,
> >>
> >> what will be the next version of QEMU after 2.9? Will we go for a 2.10
> >> (as I've seen it mentioned a c
On 24.03.2017 23:10, John Snow wrote:
>
>
> On 03/08/2017 03:26 AM, Thomas Huth wrote:
>>
>> Hi everybody,
>>
>> what will be the next version of QEMU after 2.9? Will we go for a 2.10
>> (as I've seen it mentioned a couple of times on the mailing list
>> already), or do we dare to switch to 3.0
On 03/08/2017 03:26 AM, Thomas Huth wrote:
>
> Hi everybody,
>
> what will be the next version of QEMU after 2.9? Will we go for a 2.10
> (as I've seen it mentioned a couple of times on the mailing list
> already), or do we dare to switch to 3.0 instead?
>
> I personally dislike two-digit min
On 10/03/2017 11:53, Thomas Huth wrote:
> On 10.03.2017 12:22, Peter Maydell wrote:
>> On 10 March 2017 at 12:07, Jason Wang wrote:
>>> On 2017年03月09日 18:20, Yongbok Kim wrote:
Indeed but we still use the platform to verify architectural
compatibilities even for newer MIPS architecture
On 10.03.2017 12:22, Peter Maydell wrote:
> On 10 March 2017 at 12:07, Jason Wang wrote:
>> On 2017年03月09日 18:20, Yongbok Kim wrote:
>>> Indeed but we still use the platform to verify architectural
>>> compatibilities even for newer MIPS architectures.
>
>> I see, but I believe it may need some m
On 10 March 2017 at 12:07, Jason Wang wrote:
> On 2017年03月09日 18:20, Yongbok Kim wrote:
>> Indeed but we still use the platform to verify architectural
>> compatibilities even for newer MIPS architectures.
> I see, but I believe it may need some modifications in the code to support
> newer archit
On 2017年03月09日 18:20, Yongbok Kim wrote:
On 09/03/2017 09:53, Jason Wang wrote:
On 2017年03月09日 16:50, Thomas Huth wrote:
On 09.03.2017 03:21, Jason Wang wrote:
On 2017年03月08日 19:22, Thomas Huth wrote:
On 08.03.2017 11:03, Peter Maydell wrote:
On 8 March 2017 at 09:26, Thomas Huth wrote:
Am 08.03.2017 um 09:26 hat Thomas Huth geschrieben:
> what will be the next version of QEMU after 2.9? Will we go for a 2.10
> (as I've seen it mentioned a couple of times on the mailing list
> already), or do we dare to switch to 3.0 instead?
>
> I personally dislike two-digit minor version numbe
"Daniel P. Berrange" writes:
> On Wed, Mar 08, 2017 at 12:22:24PM +0100, Thomas Huth wrote:
>> On 08.03.2017 11:03, Peter Maydell wrote:
>> > On 8 March 2017 at 09:26, Thomas Huth wrote:
>> >> But anyway, the more important thing that keeps me concerned is: Someone
>> >> once told me that we sh
On 09/03/2017 09:53, Jason Wang wrote:
>
>
> On 2017年03月09日 16:50, Thomas Huth wrote:
>> On 09.03.2017 03:21, Jason Wang wrote:
>>>
>>> On 2017年03月08日 19:22, Thomas Huth wrote:
On 08.03.2017 11:03, Peter Maydell wrote:
> On 8 March 2017 at 09:26, Thomas Huth wrote:
>> But anyway,
On 2017年03月09日 16:50, Thomas Huth wrote:
On 09.03.2017 03:21, Jason Wang wrote:
On 2017年03月08日 19:22, Thomas Huth wrote:
On 08.03.2017 11:03, Peter Maydell wrote:
On 8 March 2017 at 09:26, Thomas Huth wrote:
But anyway, the more important thing that keeps me concerned is:
Someone
once
On 09.03.2017 03:21, Jason Wang wrote:
>
>
> On 2017年03月08日 19:22, Thomas Huth wrote:
>> On 08.03.2017 11:03, Peter Maydell wrote:
>>> On 8 March 2017 at 09:26, Thomas Huth wrote:
But anyway, the more important thing that keeps me concerned is:
Someone
once told me that we shoul
On 2017年03月08日 19:22, Thomas Huth wrote:
On 08.03.2017 11:03, Peter Maydell wrote:
On 8 March 2017 at 09:26, Thomas Huth wrote:
But anyway, the more important thing that keeps me concerned is: Someone
once told me that we should get rid of old parameters and interfaces
(like HMP commands)
On Wed, Mar 08, 2017 at 12:22:24PM +0100, Thomas Huth wrote:
> On 08.03.2017 11:03, Peter Maydell wrote:
> > On 8 March 2017 at 09:26, Thomas Huth wrote:
> >> But anyway, the more important thing that keeps me concerned is: Someone
> >> once told me that we should get rid of old parameters and in
On 08.03.2017 11:03, Peter Maydell wrote:
> On 8 March 2017 at 09:26, Thomas Huth wrote:
>> But anyway, the more important thing that keeps me concerned is: Someone
>> once told me that we should get rid of old parameters and interfaces
>> (like HMP commands) primarily only when we're changing to
Hi,
> libvirt suffered similar lack of clarity around when to bump major version
> number as opposed to minor version. To address this we recently adopted the
> rule[1] that major version number changes have no relation to features. The
> major number is simply incremented at the start of each c
On Wed, Mar 08, 2017 at 09:26:00AM +0100, Thomas Huth wrote:
>
> Hi everybody,
>
> what will be the next version of QEMU after 2.9? Will we go for a 2.10
> (as I've seen it mentioned a couple of times on the mailing list
> already), or do we dare to switch to 3.0 instead?
>
> I personally disli
On 8 March 2017 at 09:26, Thomas Huth wrote:
> But anyway, the more important thing that keeps me concerned is: Someone
> once told me that we should get rid of old parameters and interfaces
> (like HMP commands) primarily only when we're changing to a new major
> version number. As you all know,
Hi everybody,
what will be the next version of QEMU after 2.9? Will we go for a 2.10
(as I've seen it mentioned a couple of times on the mailing list
already), or do we dare to switch to 3.0 instead?
I personally dislike two-digit minor version numbers like 2.10 since the
non-experienced users
36 matches
Mail list logo
