On 07/27/2011 10:33 AM, Paolo Bonzini wrote:
On 07/27/2011 02:48 PM, Anthony Liguori wrote:
So the idea here is that the PIC will multiplex a bunch of interrupts
into a single line?
Yes, but the device needs to know the interrupt number so it can expose
it through the enumerator interface. So the configuration cannot be simply
pic->irq[n] = tty->irq;
Logically, it's more similar to the ISA case, but I doubt the PIC
distributes all interrupts to everyone in real hardware.
Is the enumerator something that has an interface to devices where
the devices hold this info? Or is the enumerator just a bank of
flash that's preprogrammed with fixed info?
The former, at least in theory. Not sure if it also works that way in
real hardware, but that's the model it exposes and the way the Android
guys implemented it.
The device model provides hotplug support, so it is definitely not just
flash. Not sure again if this support is used in the hardware.
Sounds like I need to read a little about how this enumerator works. I
can't see how this would all operate without the enumerating being some
form of a bus.
At each phase, we also get significantly better modularity.
Fine, but when do we decide it's good enough to merge it?
I think we should evaluate the complexity vs. value trade off with the
character device layer (when fully converted) and make the decision in a
vacuum.
If the complexity seems too high, I can try to also convert the block
layer and we can reevaluate. I believe that just with the character
device layer, it's a net win and I don't think it can be dramatically
simplified. The patches are actually not a lot of code. The only
complexity is conceptual and that's because it takes into account a lot
of different problems.
I can even pair things down a bit by removing support for Interfaces and
simplifying class initialization of need be for the first merge.
And what if it
turns out that it's not suitable for devices? We unified some things,
but we also dug ourselves in NIH when we could have used GObject.
(GObject definitely does not work for devices, but at least we don't
need to write the infrastructure).
I tried to use GObject btw, I can share the results with you if you'd
like. Even with backends, I couldn't make properties work. GObject
uses GValues for properties which roughly models immutable values in a
variant. But I couldn't find a reasonable way to express Plugs and
Sockets in terms of GValues.
I expect that at some point in the future, GObject will grow GVariant
properties. But I still think GVariant isn't quite what it needs to be
since it still assumes immutable variants that can be copied.
I thought about just using GType but I thought using GType without using
GObject was probably not a great long term plan as I doubt anyone else
does this.
Regards,
Anthony Liguori
My only real concern is how to attack the device layer incrementally.
I don't think it's impossible but it requires careful thought.
No idea here, honestly. :)
Paolo