qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v1 00/15] data-driven device registers


From: Alistair Francis
Subject: Re: [Qemu-devel] [PATCH v1 00/15] data-driven device registers
Date: Tue, 19 Jan 2016 11:51:31 -0800

On Fri, Jan 8, 2016 at 3:05 AM, Edgar E. Iglesias
<address@hidden> wrote:
> On Fri, Jan 08, 2016 at 10:40:28AM +0000, Peter Maydell wrote:
>> On 8 January 2016 at 00:39, Alistair Francis
>> <address@hidden> wrote:
>> > On Wed, Dec 16, 2015 at 8:33 AM, Alistair Francis
>> > <address@hidden> wrote:
>> >> On Tue, Dec 15, 2015 at 1:56 PM, Peter Maydell <address@hidden> wrote:
>> >>> On 15 December 2015 at 20:52, Peter Crosthwaite
>> >>> <address@hidden> wrote:
>> >>>> It needs to exist before it can be used so there is a bit of a chicken
>> >>>> and egg problem there.
>> >
>> > No one seems to be jumping at reviewing this. Can we just send a pull 
>> > request?
>>
>> I don't necessarily require review [*]. I would like *somebody* other
>> than you Xilinx folk to say "yes, I think I would use this for
>> modelling devices". Otherwise all we have is "weird thing used
>> only in two or three Xilinx devices and nowhere else", which I'm
>> a bit reluctant to let into the tree. We already have a pretty
>> wide divergence in how devices look just based on the various
>> transitions from older to newer qdev/QOM/etc that are not complete.
>>
>> [*] by which I mean, I will review this series if you can find
>> somebody else who's going to say they'd use it.
>>
>
> Hi,
>
> I have two general comments to the series.
>
> 1. I think we need to do something to allow mem-attributes to be passed to 
> the reg-access callbacks and possibly also to add a way to filter on attrs in 
> the data structure.

I would prefer to add this in the future. We are already having enough
trouble getting it accepted now and this will add complexity.

In saying that, it shouldn't be too hard to add in the future. The
basic infrastructure is all there.

>
> 2. We had trouble in the Xilinx tree with the number of memory regions 
> created when using the style were each reg becomes an MR. I think that style 
> should either be disallowed or we need to fix the low limit (IIRC it was at 
> around 1K MRs/Regs).

This I can help with. I am sending a V2 which doesn't print the memory
regions with infro mtree. When you start getting hundreds of registers
this becomes really painful. I can't see a nice way to avoid actually
adding the memory subregions though. It is just a linked list, what
limit is there for memory subregions?

Thanks,

Alistair

>
> I'm part of the Xilinx team so I this outside of Peters review request but 
> anyawy....
>
> Cheers,
> Edgar
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]