Hi,
> > I can't see a strong reasons to change things. The docs clearly
> > recommend to use opt/ prefix to avoid conflicts. That is fine IMHO.
> >
> > I don't feel like enforcing that in code, being able to use something
> > else can be useful for debugging/testing purposes. For example the
On Tue, Jun 02, 2015 at 09:37:13AM +0200, Gerd Hoffmann wrote:
> On Mo, 2015-06-01 at 14:43 +0200, Paolo Bonzini wrote:
> >
> > On 01/06/2015 14:41, Michael S. Tsirkin wrote:
> > > On Mon, Jun 01, 2015 at 02:39:17PM +0200, Paolo Bonzini wrote:
> > >>
> > >>
> > >> On 01/06/2015 14:38, Michael S. T
On Mo, 2015-06-01 at 14:43 +0200, Paolo Bonzini wrote:
>
> On 01/06/2015 14:41, Michael S. Tsirkin wrote:
> > On Mon, Jun 01, 2015 at 02:39:17PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 01/06/2015 14:38, Michael S. Tsirkin wrote:
> >>> I'm sorry - I don't understand. It's easy to do the right
On 06/01/15 14:38, Michael S. Tsirkin wrote:
> On Mon, Jun 01, 2015 at 01:26:53PM +0200, Laszlo Ersek wrote:
>> On 06/01/15 12:48, Michael S. Tsirkin wrote:
>>> On Mon, Jun 01, 2015 at 12:43:35PM +0200, Paolo Bonzini wrote:
On 01/06/2015 12:23, Michael S. Tsirkin wrote:
> Still,
On Mon, Jun 01, 2015 at 02:39:17PM +0200, Paolo Bonzini wrote:
>
>
> On 01/06/2015 14:38, Michael S. Tsirkin wrote:
> > I'm sorry - I don't understand. It's easy to do the right thing. Just
> > add the opt prefix. Why insist on user doing the right thing, and punish
> > violations with failing a
On 01/06/2015 14:41, Michael S. Tsirkin wrote:
> On Mon, Jun 01, 2015 at 02:39:17PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 01/06/2015 14:38, Michael S. Tsirkin wrote:
>>> I'm sorry - I don't understand. It's easy to do the right thing. Just
>>> add the opt prefix. Why insist on user doing the r
On 01/06/2015 14:38, Michael S. Tsirkin wrote:
> I'm sorry - I don't understand. It's easy to do the right thing. Just
> add the opt prefix. Why insist on user doing the right thing, and punish
> violations with failing at random?
>
> If it's useful for developers somehow, add a config flag for
On Mon, Jun 01, 2015 at 01:26:53PM +0200, Laszlo Ersek wrote:
> On 06/01/15 12:48, Michael S. Tsirkin wrote:
> > On Mon, Jun 01, 2015 at 12:43:35PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 01/06/2015 12:23, Michael S. Tsirkin wrote:
> >>> Still, reserving part of the namespace for QEMU interna
On 06/01/15 12:48, Michael S. Tsirkin wrote:
> On Mon, Jun 01, 2015 at 12:43:35PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 01/06/2015 12:23, Michael S. Tsirkin wrote:
>>> Still, reserving part of the namespace for QEMU internal use
>>> is *not* policy, it's just good engineering.
>>>
>>> How about w
On 06/01/15 12:43, Paolo Bonzini wrote:
>
>
> On 01/06/2015 12:23, Michael S. Tsirkin wrote:
>> Still, reserving part of the namespace for QEMU internal use
>> is *not* policy, it's just good engineering.
>>
>> How about we forbid adding files under "etc/" ?
>>
>> That would be enough to avoid co
"Michael S. Tsirkin" writes:
> On Mon, Jun 01, 2015 at 12:43:35PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 01/06/2015 12:23, Michael S. Tsirkin wrote:
>> > Still, reserving part of the namespace for QEMU internal use
>> > is *not* policy, it's just good engineering.
>> >
>> > How about we forbi
On 01/06/2015 13:20, Markus Armbruster wrote:
> > If it's just for playing games, add a configure
> > switch to enable it, and disable by default.
> > Don't set traps for users.
>
> Document development aids as "use at your own risk", spit out scary
> warnings on use if you like, hide them from t
On 06/01/15 12:42, Michael S. Tsirkin wrote:
> On Mon, Jun 01, 2015 at 12:35:34PM +0200, Laszlo Ersek wrote:
>> On 06/01/15 12:23, Michael S. Tsirkin wrote:
>>> On Mon, Jun 01, 2015 at 11:01:23AM +0200, Paolo Bonzini wrote:
On 01/06/2015 09:28, Michael S. Tsirkin wrote:
>> I don'
On 01/06/2015 13:00, Michael S. Tsirkin wrote:
> > > If it's just for playing games, add a configure
> > > switch to enable it, and disable by default.
> > > Don't set traps for users.
> >
> > What is for playing games? What is the feature useful for, except for
> > developers.
>
> OK so if it
On Mon, Jun 01, 2015 at 12:50:50PM +0200, Paolo Bonzini wrote:
> > Someone writes a tool using a specific path.
> > We then add same path upstream, script breaks.
>
> Who cares. We documented it.
>
> >> One usecase of this feature is to avoid recompiling QEMU while playing
> >> with firmware. I
On Mon, Jun 01, 2015 at 12:50:50PM +0200, Paolo Bonzini wrote:
>
>
> On 01/06/2015 12:48, Michael S. Tsirkin wrote:
> > On Mon, Jun 01, 2015 at 12:43:35PM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 01/06/2015 12:23, Michael S. Tsirkin wrote:
> >>> Still, reserving part of the namespace for QEM
On 01/06/2015 12:48, Michael S. Tsirkin wrote:
> On Mon, Jun 01, 2015 at 12:43:35PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 01/06/2015 12:23, Michael S. Tsirkin wrote:
>>> Still, reserving part of the namespace for QEMU internal use
>>> is *not* policy, it's just good engineering.
>>>
>>> How abo
On Mon, Jun 01, 2015 at 12:43:35PM +0200, Paolo Bonzini wrote:
>
>
> On 01/06/2015 12:23, Michael S. Tsirkin wrote:
> > Still, reserving part of the namespace for QEMU internal use
> > is *not* policy, it's just good engineering.
> >
> > How about we forbid adding files under "etc/" ?
> >
> > T
On 01/06/2015 12:23, Michael S. Tsirkin wrote:
> Still, reserving part of the namespace for QEMU internal use
> is *not* policy, it's just good engineering.
>
> How about we forbid adding files under "etc/" ?
>
> That would be enough to avoid conflicts.
I do not understand. What we're doing i
On Mon, Jun 01, 2015 at 12:35:34PM +0200, Laszlo Ersek wrote:
> On 06/01/15 12:23, Michael S. Tsirkin wrote:
> > On Mon, Jun 01, 2015 at 11:01:23AM +0200, Paolo Bonzini wrote:
> >>
> >>
> >> On 01/06/2015 09:28, Michael S. Tsirkin wrote:
> I don't feel overly strongly about it; just "mechanism
On 06/01/15 12:23, Michael S. Tsirkin wrote:
> On Mon, Jun 01, 2015 at 11:01:23AM +0200, Paolo Bonzini wrote:
>>
>>
>> On 01/06/2015 09:28, Michael S. Tsirkin wrote:
I don't feel overly strongly about it; just "mechanism, not policy"
looks like a good tradition (well, good excuse anyway).
On Mon, Jun 01, 2015 at 11:01:23AM +0200, Paolo Bonzini wrote:
>
>
> On 01/06/2015 09:28, Michael S. Tsirkin wrote:
> > > I don't feel overly strongly about it; just "mechanism, not policy"
> > > looks like a good tradition (well, good excuse anyway).
> >
> > Most users never see warnings. We sh
On 01/06/2015 09:28, Michael S. Tsirkin wrote:
> > I don't feel overly strongly about it; just "mechanism, not policy"
> > looks like a good tradition (well, good excuse anyway).
>
> Most users never see warnings. We ship it, we support it.
> If we don't want to support it, let's not ship it.
T
On Mon, Jun 01, 2015 at 09:06:19AM +0200, Laszlo Ersek wrote:
> On 05/31/15 20:10, Michael S. Tsirkin wrote:
> > On Wed, Apr 29, 2015 at 11:21:53AM -0400, Gabriel L. Somlo wrote:
> >> Allow user supplied files to be inserted into the fw_cfg
> >> device before starting the guest. Since fw_cfg_add_fi
On 05/31/15 20:10, Michael S. Tsirkin wrote:
> On Wed, Apr 29, 2015 at 11:21:53AM -0400, Gabriel L. Somlo wrote:
>> Allow user supplied files to be inserted into the fw_cfg
>> device before starting the guest. Since fw_cfg_add_file()
>> already disallows duplicate fw_cfg file names, qemu will
>> ex
On Wed, Apr 29, 2015 at 11:21:53AM -0400, Gabriel L. Somlo wrote:
> Allow user supplied files to be inserted into the fw_cfg
> device before starting the guest. Since fw_cfg_add_file()
> already disallows duplicate fw_cfg file names, qemu will
> exit with an error message if the user supplies multi
Allow user supplied files to be inserted into the fw_cfg
device before starting the guest. Since fw_cfg_add_file()
already disallows duplicate fw_cfg file names, qemu will
exit with an error message if the user supplies multiple
blobs with the same fw_cfg file name, or if a blob name
collides with
27 matches
Mail list logo
