Tigran Aivazian <tigran@veritas.com> 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
syscalls?
This may require some sort of in-the-main-kernel syscall register/unregister
functionality that takes a handler pointer _and_ a module definition pointer.
David
-
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 : Thu Sep 07 2000 - 21:00:29 EST