Markus Armbruster writes:
[...]
> To make forward progress, I recommend to split this patch into an
> uncontroversial and a controversial part. The uncontroversial part are
> the RFQDN rules.
I offered Michael to do that for him, and he accepted. Patch is on its
way.
On Fri, Apr 15, 2016 at 05:39:33PM +0200, Markus Armbruster wrote:
> [Context restored]
>
> "Michael S. Tsirkin" writes:
>
> > On Thu, Apr 14, 2016 at 01:29:20PM +0200, Markus Armbruster wrote:
> >> The next use case to consider is a user picking a new name for a new
> >> interface between host
[Context restored]
"Michael S. Tsirkin" writes:
> On Thu, Apr 14, 2016 at 01:29:20PM +0200, Markus Armbruster wrote:
>> The next use case to consider is a user picking a new name for a new
>> interface between host and guest. I find the idea that such a user
>> won't notice warnings farfetched.
On Thu, Apr 14, 2016 at 01:29:20PM +0200, Markus Armbruster wrote:
> What good is that going to do?
Enforce a sane policy. It's too easy to misconfigure qemu as it is.
We don't need more knobs that can break guests.
--
MST
"Michael S. Tsirkin" writes:
> On Thu, Apr 14, 2016 at 09:39:07AM +0200, Markus Armbruster wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > On Wed, Apr 13, 2016 at 06:19:55PM +0200, Markus Armbruster wrote:
>> >> "Michael S. Tsirkin" writes:
>> >>
>> >> > On Wed, Apr 13, 2016 at 10:59:35AM +020
"Michael S. Tsirkin" writes:
> On Thu, Apr 14, 2016 at 09:36:28AM +0200, Markus Armbruster wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > On Wed, Apr 13, 2016 at 06:17:29PM +0200, Markus Armbruster wrote:
>> >> "Michael S. Tsirkin" writes:
>> >>
>> >> > On Wed, Apr 13, 2016 at 10:59:35AM +020
On Thu, Apr 14, 2016 at 09:39:07AM +0200, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > On Wed, Apr 13, 2016 at 06:19:55PM +0200, Markus Armbruster wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > On Wed, Apr 13, 2016 at 10:59:35AM +0200, Markus Armbruster wrote:
> >> >> If
On Thu, Apr 14, 2016 at 09:36:28AM +0200, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > On Wed, Apr 13, 2016 at 06:17:29PM +0200, Markus Armbruster wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > On Wed, Apr 13, 2016 at 10:59:35AM +0200, Markus Armbruster wrote:
> >> >> I h
"Michael S. Tsirkin" writes:
> On Wed, Apr 13, 2016 at 06:19:55PM +0200, Markus Armbruster wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > On Wed, Apr 13, 2016 at 10:59:35AM +0200, Markus Armbruster wrote:
>> >> If we can protect them without
>> >> complicating or breaking stuff, sure, why not.
"Michael S. Tsirkin" writes:
> On Wed, Apr 13, 2016 at 06:17:29PM +0200, Markus Armbruster wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > On Wed, Apr 13, 2016 at 10:59:35AM +0200, Markus Armbruster wrote:
>> >> I have a hard time coming up with realistic unclean breakage.
>> >
>> > The issue is
On Wed, Apr 13, 2016 at 06:17:29PM +0200, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > On Wed, Apr 13, 2016 at 10:59:35AM +0200, Markus Armbruster wrote:
> >> I have a hard time coming up with realistic unclean breakage.
> >
> > The issue is that Linux is now exposing fw cfg to u
On Wed, Apr 13, 2016 at 06:19:55PM +0200, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > On Wed, Apr 13, 2016 at 10:59:35AM +0200, Markus Armbruster wrote:
> >> If we can protect them without
> >> complicating or breaking stuff, sure, why not. But not at all costs.
> >
> > The stu
"Michael S. Tsirkin" writes:
> On Wed, Apr 13, 2016 at 10:59:35AM +0200, Markus Armbruster wrote:
>> If we can protect them without
>> complicating or breaking stuff, sure, why not. But not at all costs.
>
> The stuff we break is precisely the stuff our warnings
> say might break at any time. So
"Michael S. Tsirkin" writes:
> On Wed, Apr 13, 2016 at 10:59:35AM +0200, Markus Armbruster wrote:
>> I have a hard time coming up with realistic unclean breakage.
>
> The issue is that Linux is now exposing fw cfg to userspace.
> So it's use is about to expand significantly.
>
> This is what I am
On Wed, Apr 13, 2016 at 10:59:35AM +0200, Markus Armbruster wrote:
> If we can protect them without
> complicating or breaking stuff, sure, why not. But not at all costs.
The stuff we break is precisely the stuff our warnings
say might break at any time. So since you believe users
might be relied
On Wed, Apr 13, 2016 at 10:59:35AM +0200, Markus Armbruster wrote:
> I have a hard time coming up with realistic unclean breakage.
The issue is that Linux is now exposing fw cfg to userspace.
So it's use is about to expand significantly.
This is what I am trying to prevent:
- in 2016, users build
"Michael S. Tsirkin" writes:
> On Mon, Apr 11, 2016 at 01:04:14PM +0200, Markus Armbruster wrote:
>> My best guess
>> is you're referring to the part where I challenge mapping
>> /unsupported/root/FOO to FOO. I find that baroque. I can accept
>> baroque when I see a reason. That's why I asked
On Mon, Apr 11, 2016 at 01:04:14PM +0200, Markus Armbruster wrote:
> My best guess
> is you're referring to the part where I challenge mapping
> /unsupported/root/FOO to FOO. I find that baroque. I can accept
> baroque when I see a reason. That's why I asked for it. "I got ACKs
> for it" is not
"Michael S. Tsirkin" writes:
> On Fri, Apr 08, 2016 at 06:31:55PM +0200, Markus Armbruster wrote:
>> Interface and doc review only. Sorry for the delay, I was on vacation.
>>
>> "Michael S. Tsirkin" writes:
>>
>> > This requires that all -fw_cfg command line users use names of the form
>>
>>
On Fri, Apr 08, 2016 at 06:31:55PM +0200, Markus Armbruster wrote:
> Interface and doc review only. Sorry for the delay, I was on vacation.
>
> "Michael S. Tsirkin" writes:
>
> > This requires that all -fw_cfg command line users use names of the form
>
> What's "this"? Do you mean "Require th
Interface and doc review only. Sorry for the delay, I was on vacation.
"Michael S. Tsirkin" writes:
> This requires that all -fw_cfg command line users use names of the form
What's "this"? Do you mean "Require that ..."?
> opt/RFQDN/: such names are compatible with QEMU 2.4 and 2.5 as well a
21 matches
Mail list logo
