Messages in this thread | | | From | David Woodhouse <> | Subject | Re: [RFC] Wine speedup through kernel module | Date | Wed, 13 Sep 2000 12:23:05 +0100 |
| |
David.Howells@nexor.co.uk said: > I didn't know how to get hold of a "struct pt_regs*" till someone sent > me a message this morning
Ah. I didn't realise you wanted the struct pt_regs for any purpose other than to pass to the lcall7 handler - and I was no longer using the lcall7 handler in the sys_win32 stub I posted to you and linux-kernel yesterday afternoon.
> int (*sys_win32_handler)(args...); > EXPORT_SYMBOL(sys_win32_handler); > > int sys_win32(args...) > { > ret = -ENOSYS; > > if (current->personality != PER_WIN32) { > if (sys_personality(PER_WIN32)) > return -ENOSYS; > } > /* Now the process has the WIN32 personality, so until it > exits, we know the module cannot be unloaded. > */ > > return (*sys_win32_handler)(args...); > } > > Code your win32 support module to register the PER_WIN32 personality, and > set the sys_win32_handler pointer appropriately.
David.Howells@nexor.co.uk said: > Because "getting" the struct file from the fd increments the usage > count on the struct file. The VFS automatically maintains the module > count pointed to by the file_operations structure based on the > existence of the struct file.
Aha. It's a device node provided by the same module? But what happens when the syscall is invoked with a fd which _isn't_ correct?
-- dwmw2
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
| |