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/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:20 EST