[lkml]   [2000]   [Sep]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] Wine speedup through kernel module

"J. Robert von Behren" <> 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.020 / U:2.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site