lkml.org 
[lkml]   [2000]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] Wine speedup through kernel module
Date

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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.048 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site