[lkml]   [2000]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Wine speedup through kernel module

    Tigran Aivazian <> wrote:
    > how about the classical standard way of "getting to kernel space", i.e.
    > plain system calls? Unless you really need a huge number of new system
    > calls,

    Just the one... this'll take a parameter specifying the Win32 call to make:

    int win32(int fd, enum win32op, void *args, u_int *win32error)

    The fd is currently used to find the Win32 handle map, which is attached to
    struct file->f_private on that fd. I don't know any other way of doing this at
    the moment (at least so the handle map automatically gets destroyed when the
    owning process expires).

    One thing that might be useful in this regard is the ability to add callbacks
    into a list on the task structure, such that they are invoked when the process
    exits/execs (and at no other time).

    > what you can do is in the module, scan for sys_ni_syscall entries
    > in the sys_call_table[] table (see entry.S) and replace them with pointers
    > to functions in your module's address space. Then you need to communicate
    > the slot numbers thus occupied back to userspace, e.g. via /proc file
    > which then can invoke them in a standard int 0x80 manner.

    Yes... that's a good idea... I already use a /proc file to provide access to
    the kernel module, I can just extend that.

    > Or you can hardcode the slots but that is not flexible because unoccupied
    > slots may become occupied at any time in the future.

    Unless I can get one reserved, though I suspect that won't happen.

    > Also, if you do this - don't forget to inc/dec module refcount in each of
    > your new syscalls, for obvious reasons - if the syscall sleeps and the
    > module is unloaded, it will return to "nowhere".

    That is actually quite a big problem... How do you stop someone accessing the
    syscall whilst the module's cleanup function is running, but before it has a
    chance to clear the syscall slot? Does module unloading lock out other

    This may require some sort of in-the-main-kernel syscall register/unregister
    functionality that takes a handler pointer _and_ a module definition pointer.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:38    [W:0.020 / U:50.140 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site