Il 07/10/2014 20:41, Kevin Wolf ha scritto:
> Is there any way to add netdevs/chardevs/devices in a non-QemuOpts way?
For chardevs, yes.
> I think always checking for the same allowed set of characters is the
> only sane way to do things. Otherwise you end up with names that can be
> used in one
Il 07/10/2014 20:39, Markus Armbruster ha scritto:
>> > 1) always use the same restriction when a user creates objects;
>> >
>> > 2) do not introduce restrictions when a user is not using QemuOpts.
>> >
>> > We've been doing (2) so far; often it is just because QMP wrappers
Am 07.10.2014 um 17:14 hat Paolo Bonzini geschrieben:
> Il 07/10/2014 14:16, Markus Armbruster ha scritto:
> >> > Possibly, except this would propagate all the way through the APIs. For
> >> > example, right now [*] is added automatically to MemoryRegion
> >> > properties, but this can change in t
Paolo Bonzini writes:
> Il 07/10/2014 14:16, Markus Armbruster ha scritto:
>>> > Possibly, except this would propagate all the way through the APIs. For
>>> > example, right now [*] is added automatically to MemoryRegion
>>> > properties, but this can change in the future since many MemoryRegion
Il 07/10/2014 14:16, Markus Armbruster ha scritto:
>> > Possibly, except this would propagate all the way through the APIs. For
>> > example, right now [*] is added automatically to MemoryRegion
>> > properties, but this can change in the future since many MemoryRegions
>> > do not need array-like
Paolo Bonzini writes:
> Il 07/10/2014 10:01, Markus Armbruster ha scritto:
>> "Automatic arrayification" isn't about array-valued properties, it's a
>> convenience feature for creating a bunch of properties with a common
>> type, accessors and so forth, named in a peculiar way: "foo[0]",
>> "foo[
Il 07/10/2014 10:01, Markus Armbruster ha scritto:
> "Automatic arrayification" isn't about array-valued properties, it's a
> convenience feature for creating a bunch of properties with a common
> type, accessors and so forth, named in a peculiar way: "foo[0]",
> "foo[1]", ...
>
> The feature save
[Quoted material edited somewhat to provide better context]
Paolo Bonzini writes:
> Il 02/10/2014 16:59, Markus Armbruster ha scritto:
>> Andreas Färber writes:
>>
>>> Am 02.10.2014 um 16:21 schrieb Markus Armbruster:
Andreas Färber writes:
> Am 02.10.2014 um 15:21 schrieb Stefa
Il 02/10/2014 16:59, Markus Armbruster ha scritto:
> Andreas Färber writes:
>
>> Am 02.10.2014 um 16:21 schrieb Markus Armbruster:
>>> Andreas Färber writes:
>>>
Am 02.10.2014 um 15:21 schrieb Stefan Hajnoczi:
> On Wed, Oct 01, 2014 at 02:33:47PM +0200, Markus Armbruster wrote:
>> M
Andreas Färber writes:
> Am 02.10.2014 um 16:21 schrieb Markus Armbruster:
>> Andreas Färber writes:
>>
>>> Am 02.10.2014 um 15:21 schrieb Stefan Hajnoczi:
On Wed, Oct 01, 2014 at 02:33:47PM +0200, Markus Armbruster wrote:
> Markus Armbruster writes:
This discussion seems or
Am 02.10.2014 um 16:21 schrieb Markus Armbruster:
> Andreas Färber writes:
>
>> Am 02.10.2014 um 15:21 schrieb Stefan Hajnoczi:
>>> On Wed, Oct 01, 2014 at 02:33:47PM +0200, Markus Armbruster wrote:
Markus Armbruster writes:
>>>
>>> This discussion seems orthogonal to your patch. But I'm n
Andreas Färber writes:
> Am 02.10.2014 um 15:21 schrieb Stefan Hajnoczi:
>> On Wed, Oct 01, 2014 at 02:33:47PM +0200, Markus Armbruster wrote:
>>> Markus Armbruster writes:
>>
>> This discussion seems orthogonal to your patch. But I'm not applying it
>> yet to give more time for discussion/rev
On Thu, Oct 02, 2014 at 03:26:28PM +0200, Andreas Färber wrote:
> Am 02.10.2014 um 15:21 schrieb Stefan Hajnoczi:
> > On Wed, Oct 01, 2014 at 02:33:47PM +0200, Markus Armbruster wrote:
> >> Markus Armbruster writes:
> >
> > This discussion seems orthogonal to your patch. But I'm not applying it
Am 02.10.2014 um 15:21 schrieb Stefan Hajnoczi:
> On Wed, Oct 01, 2014 at 02:33:47PM +0200, Markus Armbruster wrote:
>> Markus Armbruster writes:
>
> This discussion seems orthogonal to your patch. But I'm not applying it
> yet to give more time for discussion/review of the patch.
>
>> Is mangl
On Wed, Oct 01, 2014 at 02:33:47PM +0200, Markus Armbruster wrote:
> Markus Armbruster writes:
This discussion seems orthogonal to your patch. But I'm not applying it
yet to give more time for discussion/review of the patch.
> Is mangling array-ness into the name really a good idea? Isn't this
Markus Armbruster writes:
> IDs have long spread beyond QemuOpts: not everything with an ID
> necessarily goes through QemuOpts. Commit 9aebf3b is about such a
> case: block layer names are meant to be well-formed IDs, but some of
> them don't go through QemuOpts, and thus weren't checked. The
16 matches
Mail list logo
