On 13.02.2011, at 13:44, David Gibson wrote: > On Sun, Feb 13, 2011 at 01:40:14PM +0100, Alexander Graf wrote: >> >> On 13.02.2011, at 12:14, David Gibson wrote: >> >>> On Sun, Feb 13, 2011 at 10:15:03AM +1100, Benjamin Herrenschmidt wrote: >>>> On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote: >>>>> On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herrenschmidt >>> [snip] >>>> Actually, one thing I noticed is that the current patches David posted >>>> still have a single function with a switch/case statement for hcalls. >>>> >>>> I'm not 100% certain what David long term plans are here, but in our >>>> internal "WIP" tree, we've subsequently turned that into a mechanism >>>> where any module can call powerpc_register_hypercall() to add hcalls. >>>> >>>> So if David intends to move the "upstream candidate" tree in that >>>> direction, then naturally, the calls in spapr_hcall.c are going to >>>> disappear in favor of a pair of powerpc_register_hypercall() locally in >>>> the vty module. >>> >>> Ah, yeah. I'm still not sure what to do about it. I was going to >>> fold the dynamic hcall registration into the patch set before >>> upstreaming. But then something paulus said made me rethink whether >>> the dynamic registration was a good idea. Still need to sort this out >>> before the series is really ready. >> >> We can surely move it to dynamic later on. I think the "proper" way >> would be to populate a qdev bus and have the individual hypercall >> receivers register themselves through -device creations. But Blue >> really is the expert here :). > > Ok, not sure what you mean here. I already have a qdev bus for the > VIO devices. With my tentative dynamic model as devices are created > on the bus they may register hypercalls as well.
Oh, guess I just overlooked that then, sorry :). > Is that what you mean, or do you mean have a separate "hypercall" > bus. That sounds like serious overkill for a simple number->function > translation. Yup. Alex
