[EMAIL PROTECTED] (Ramon van Handel) wrote:
> >>> - if (!create_proc_info_entry("freemware", 0, NULL, fmw_read_procmem))
> >>> + if (!create_proc_info_entry("freemware", 0, NULL, (void
> >>>*)fmw_read_procmem))
> >>
> >>Oops. Is there a argument type mismatch? Don't hide it, fix it ;-)
> >Yes, came a compiler warning. Guess it should be a void *, so the compiler
> >is friendly ;)
>
> Shouldn't we compile everything with -Wall ?
We do, actually. What I assume is that the create_proc_info_entry
gets as argument a pointer to function with slightly different
arguments (probably depending on the kernel version). We should
find out the exact parameter types expected, and declare our
fmw_read_procmem routine correctly, possibly with #ifdef's
depending on the kernel version.
(In any case, void * is just cheating: it just tells the compiler
to ignore any and all type mismatches.)
[snip]
> >Perhaps we should add an ioctl for translating virtual to linear
> >and physical addresses for the case we don't have a flat memory
> >model or paging in the guest. For plugins to calculate adresses
> >given by segment selector and offset.
>
> That would be a good idea.
Note that virtually contiguous regions need not be physically
contiguous: this means that even if you just access a WORD,
you have to consider the case where it crosses page boundaries ...
It might be simpler to just have a copy_to/from_guest ioctl
to access guest virtual memory. (We could have both, of course.
Or we could have an address translation ioctl plus a copy_...
helper routine in user space ...)
> >+ case EMU_INSTR_INS_8:
> >+ plugin_emulate(EVT_INPORT,context.edx & 0xffff,1,1,&value);
>
> As an optimisation, we could support "rep insb" etc. by providing a value
> array that has multiple elements.
Of course. That's why we pass a count in the first place ;-)
> Another thing: right now, the plugins are responsible for positioning
> the return value, in %eax or something. However, I don't think this is a
> good idea, really... I think we should add "return" array in the same way
> as the "value" array to plugin_emulate, and that main_run_loop() is then
> responsible for returning this to the guest. I'll work on this ASAP.
I've already fixed this: values are returned in the value array as well.
Bye,
Ulrich
