> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Keir Fraser
> Sent: 18 May 2006 14:15
> To: Petersson, Mats
> Cc: Xen devel list
> Subject: Re: [Xen-devel] Re: X86_emulate to be moved into qemu...
>
>
> On 18 May 2006, at 13:58, Petersson, Mats wrote:
>
> > So, that would be a struct that could have the "struct 
> ioreq" field in 
> > it, which is optionally filled in depending on where it's 
> called from, 
> > for example?
> >
> > Yes, I agree with this.
> >
> > I'll work on something that uses this method, and I'll send you a 
> > patch before I go any further.
>
> My model would be that any *extra* stuff you want to just 
> pass through to the callback functions, you'd do as follows (roughly):
>
> /* This is a container for all emulation context. */ struct 
> mydevice_emulator_context {
> /* The actual args structure for the emulator. */
> struct x86_emulate args;
> /* Extra handy stuff for this particular call site and 
> set of callback functions. */
> struct ioreq *ioreq;
> };
>
> /* This is a call to the emulator. */
> x86_emulate_memop(&context.args);
>
> /* This is an example of how a callback func gets at the 
> caller-specific goodies. */ int emulate_read(..., struct 
> x86_emulate_memop *args) {
> struct mydevice_emulator_context *context;
> context = container_of(args, struct 
> mydevice_emulator_context, args);
> ....
> }
Ok, I'm with you. 
Attached is a quick hack at getting a single argument to
x86_emulate_memop() and related changes. Comments please...
--
Mats
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel 
>
>

Attachment: single_struct_arg.patch
Description: single_struct_arg.patch

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel