Messages in this thread |  | | Date | Fri, 08 Sep 2000 16:12:58 -0700 | From | "J. Robert von Behren" <> | Subject | Re: [RFC] Wine speedup through kernel module |
| |
Hey David -
Since at least two of us agree that having dynamically allocated syscall table entries would be handy, perhaps that is worth pursuing. I suppose the one issue (as you mention below) is that you might need a large number of these free entries. Does anyone know if there would be any adverse side effect to doubleing or quadrupling the size of the system call table? At first blush, I can't think of any reasons not to.
That said, as a stopgap, I still believe a char device could do the trick....
> "J. Robert von Behren" <jrvb@cs.berkeley.edu> wrote: > > FWIW, this can be done with relatively low overhead by creating a > > miscelaneous character device, and just using write() to write in the > > arguments. This is a bit worse than passing things through registers, > > but doesn't seem all that bad. > > How do you emulate calls that return more than just a single integer?
As one of the function arguments (that are written to the char device) just pass in a pointer to a user-space buffer, and have the kernel fill it in w/ appropriate data for that call. You can do the same thing as read() or others, its just that the args are passed via a memory copy, rather than in registers. If you actually want to return a large struct as a return value, you'd need to do some sort of kernel to user copy anyway - the only difference is that it would go onto the stack instead. Passing in a buffer seems cleaner to me.
> Plus if > you do it that way, someone can play havoc with the system with the cat > command, or if something tries to use the wrong fd.
No. The way it would work is that you would open up the character device from user space. All fops to the returned FD, are passed to the module code. The module code reads in the data from the write() call, translates this to arguments, and then does the same sanity checking that any system call should do (make sure pointers refer to things in the user's address space, copy data to kernel space, etc.)
Basically an academic point, though, since dynamic management of the system call table would seem to be cleaner.
-Rob - 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/
|  |