On Mon, Sep 19, 2016 at 12:51:46PM +0200, Alexander Graf wrote:
> 
> 
> On 16.09.16 15:30, Christoffer Dall wrote:

[...]

> > 
> > That being said, I'm not categorically against these patches, but I
> > share Marc's view that we've already seen that non-vgic support had been
> > broken for multiple versions without anyone complaining, and without
> > automated testing or substantial interest in the work, the patches
> > really are likely to bit-rot.
> 
> I know that it's very hard to grasp from an upstream maintainer
> perspective, 

pfff

> but keep in mind where the bulk of execution of kernel code
> lies. The average life cycle of a "stable" Linux distribution's kernel
> is a few years.
> 
> So far all regressions in the user space gic code have been found within
> less than 1y of the respective code release. I'd say that counts for
> quite a well used feature.
> 

The only report I can think of about this was Pavel using an upstream
kernel for in-house Samsung development on non-public hardware.

But, again, I didn't look at the patches in detail yet, I'm not
categorically against them, I will take a careful look at them like I do
with all patches on the kvmarm list.  There's a risk they'll break in
mainline unless we sort out our testing story, and it may just be
something we'll have to live with.

> > But I haven't even looked at the patches in detail, I was just replying
> > to the comment about testing.
> 
> Also keep in mind that without the architected timer support (and/or
> without qemu patches than enable user space timers) the user space gic
> support is pretty unusable to most people, so you obviously get less
> reports.
>

I don't disagree with this.  I don't know what this has to do with the
part of my mail you're replying to, but I completely agree that the
current userspace irqchip support has limited value.

-Christoffer
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Reply via email to