Messages in this thread |  | | Subject | Re: [RFC] Wine speedup through kernel module | Date | Mon, 11 Sep 2000 09:15:26 +0100 | From | David Howells <> |
| |
"J. Robert von Behren" <jrvb@cs.berkeley.edu> wrote: > 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.
I think just grabbing a single dynamic syscall and passing that an operation ID is the better way... Otherwise we probably have to export a large number of dynamic syscall numbers for userspace to find.
> That said, as a stopgap, I still believe a char device could do the > trick....
Not really all that much difference in internal implementation. Just that a char device requires allocation of a major device number.
> 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.
My point is that read and write have pretty well defined semantics... and I don't think it'd be a good idea to deviate from them. A side effect of a write that changed some of the process's memory space would be bad.
Plus, it is entirely possible to accidentally construct valid data...
David Howells - 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/
|  |