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
> "J. Robert von Behren" <email@example.com> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:11 EST