"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/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:14 EST