[EMAIL PROTECTED] 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.
[EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
