On 10/26/2010 05:09 PM, Blue Swirl wrote:
On Tue, Oct 26, 2010 at 8:05 AM, Avi Kivity<avi@xxxxxxxxxx> wrote:
> On 10/25/2010 08:38 PM, Blue Swirl wrote:
>>
>> >
>> > I don't really see why we need registration; cpu_register_io() takes
>> > function pointers, a size, and an opaque, and gives an integer handle
>> > in
>> > return. With the IOPort object approach, you set up the IOPort with
>> > function pointers, size is implied, and the opaque is derived using
>> > container_of(); the handle is simply the address of the object.
>>
>> With the handle, we can separate setting up the structures at device
>> level, and mapping the object using only the handle at bus or other
>> higher level. Can this be done with the object approach?
>
> I believe so. The handle is simply an indirect pointer, no?
Yes, but then the object should also contain size information. That
should not be needed for mapping at higher level.
Sorry, I don't follow your meaning.
When I said "size is implied" I meant that the IOPort object has a
separate function pointer for sizes 1, 2, and 4, so it ioport_register()
doesn't need a size parameter. But I don't see how that relates to your
comment.
>> The purpose of that patch series was to perform the separation for PCI
>> BARs. I wasn't so happy with the series, so I never pushed.
>
> In fact I think an IOPort is even more suitable; if we need additional
> attributes we can use a derived object:
>
> struct PCIIOPort {
> IOPort ioport;
> /* additional fields */
> };
One issue with my series was that it would be great if the devices
just had some BAR structures (used by PCI layer to map the devices)
inside PCI/qdev structures, but I invented that too late. Maybe this
can be addressed in your design?
It looks to be orthogonal. It would be great to have a BAR object; that
object can then use your API, my API, or the existing API.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
