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.
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.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
