qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 15/15] Implement the bus structure for PAPR virt


From: Benjamin Herrenschmidt
Subject: [Qemu-devel] Re: [PATCH 15/15] Implement the bus structure for PAPR virtual IO
Date: Sun, 13 Feb 2011 10:15:03 +1100

On Sun, 2011-02-13 at 00:52 +0200, Blue Swirl wrote:
> On Sat, Feb 12, 2011 at 11:00 PM, Benjamin Herrenschmidt
> <address@hidden> wrote:
> > On Sat, 2011-02-12 at 18:59 +0200, Blue Swirl wrote:
> >>
> >> Actually I don't quite understand the need for vty layer, why not use
> >> the chardev here directly?
> >
> > I'm not sure what you mean here...
> 
> Maybe it would be reasonable to leave h_put_term_char to spapr_hcall.c
> instead of moving those to a separate file.

Well, the VIO device instance gives the chardev instance which is all
nicely encapsulated inside spapr-vty... Also VIO devices tend to have
dedicated hcalls, not only VTY, so it makes a lot of sense to keep them
close to the rest of the VIO driver they belong to don't you think ?

(Actually veth does, vscsi uses the more "generic" CRQ stuff which we've
added to the core VIO but you'll see that when we get those patches
ready, hopefully soon).

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.

Cheers,
Ben.




reply via email to

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