Re: [RFC] Wine speedup through kernel module
Alexander Viro <[EMAIL PROTECTED]> wrote: > Then these apps are non-portable to other Unices and either get fixed or > get rm'd. Period. Definitely. > In case you've missed that, Win32 is misdesigned crap. It's one thing > to add binary compatibility _if_ it doesn't affect the native stuff, but > merging that abortion into the native API Just Is Not Going To Happen. I agree with you on that. I'd quite like a Win32 API to be available, but I wouldn't like it to have too much impact on the main Linux kernel. I presume that you don't have a problem with it implemented in a module for use in accelerating Wine? > The longer I'm looking at that thread the more it looks like an attempt to > merge incompatible models. Last time that happened we got Missed'em'V and > that's going to be _much_ worse. Mixing v7 with CP/M gave DOS. List goes > on and on and there is _nothing_ but shit on it. True the two are pretty much incompatible... but I can implement a large amount of the basic Win32 API in kernel space without affecting on the rest of the kernel. I will, however, supply a couple of patches to add useful extra features that are internal to the kernel anyway, and don't affect the userspace API semantics. These include process death notification (which someone else expressed interest in for some other purpose) and some optional hooks to make it faster and easier to use my implementation. > Folks, get real - if you want NT you know where to find it. Yes - written on the reverse of my cup mat *grin*. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
"Albert D. Cahalan" <[EMAIL PROTECTED]> wrote: > Well, if this isn't worth doing right... Patch size is just something > you have to deal with. Hopefully you can get an early-2.5.x merge. I wouldn't like to bet on it. > Why limit it? If the existing poll method needs extension, do it. I suppose so. On a separate issue, the more I look at the poll and select implementation, the more I'm convinced there's a leak, but I'm not sure it matters. > That may be, but we deal with it all the time. The VFS code has to > be well-optimized and SMP-safe. Besides, many of these Win32 handles > will refer to files anyway, won't they? Run HandleEx sometime... most of the handles are generally not files, particularly for a program that uses the perfmon stuff, when it uses heaps of registry handles and section handles. > > * The dentry filename support does not handle separate namespaces. > > By this you mean...? Can you not just apply a prefix? > Perhaps you could use the half-way mounted filesystems, > with some way to specify the desired filesystem root. Actually, I suppose could look at how /proc does things. Make anonymous objects just numbered files in a special directory. > Well, that would be generally useful for Linux software. But hard to achieve at the moment... Not only would the VFS have to change, but all the filesystems too. > Also useful: an open-read-close operation that doesn't muck around > with fd allocation. Maybe hang the data off of a struct stat, so that > callers can atomicly get everything. Better still, just give the syscall a filename, a buffer and a buffer size. > > * Win32 access/share flags would have to be retained in the file > > struct, and the inode struct would have to maintain a list of these. > > OK. Problem? Not a nice thing to add. Care has been taken to decouple the file from the inode (a dentry sandwich). Also it means more maintanence work on the part of the VFS. Care would also have to be taken to avoid a reference count loop: File points to Inode points to File. Not insurmountable though. > The list would be NULL most of the time. If Linux apps start > using this feature a lot, then it can be optimized. No. The list could never be NULL. > Excuse me? Does Win32 not allow rename of open files? It does, but the internal object name does not change. You cannot create a new file of the old name whilst it is still open internally. > Assuming that is the problem, you have a few options I think. > You could let handles block rename, except that you might let > root override restrictions caused by non-root users. *shiver* > You could just ignore this problem and see what, if anything, breaks. I really don't like doing that. It's always an important customer who falls over it. > You could lie I suppose, supplying old names as needed. Then you should stick with the current system. > Doesn't that strike you as being a hack that will cause you > to need _more_ code in the end? No. > You'll end up writing a second VFS layer if I'm not mistaken. No I won't. I wasn't really thinking in terms of having a process handles map as a directory full of fd's, more like a flat file with a list in it. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
"Albert D. Cahalan" [EMAIL PROTECTED] wrote: Well, if this isn't worth doing right... Patch size is just something you have to deal with. Hopefully you can get an early-2.5.x merge. I wouldn't like to bet on it. Why limit it? If the existing poll method needs extension, do it. I suppose so. On a separate issue, the more I look at the poll and select implementation, the more I'm convinced there's a leak, but I'm not sure it matters. That may be, but we deal with it all the time. The VFS code has to be well-optimized and SMP-safe. Besides, many of these Win32 handles will refer to files anyway, won't they? Run HandleEx sometime... most of the handles are generally not files, particularly for a program that uses the perfmon stuff, when it uses heaps of registry handles and section handles. * The dentry filename support does not handle separate namespaces. By this you mean...? Can you not just apply a prefix? Perhaps you could use the half-way mounted filesystems, with some way to specify the desired filesystem root. Actually, I suppose could look at how /proc does things. Make anonymous objects just numbered files in a special directory. Well, that would be generally useful for Linux software. But hard to achieve at the moment... Not only would the VFS have to change, but all the filesystems too. Also useful: an open-read-close operation that doesn't muck around with fd allocation. Maybe hang the data off of a struct stat, so that callers can atomicly get everything. Better still, just give the syscall a filename, a buffer and a buffer size. * Win32 access/share flags would have to be retained in the file struct, and the inode struct would have to maintain a list of these. OK. Problem? Not a nice thing to add. Care has been taken to decouple the file from the inode (a dentry sandwich). Also it means more maintanence work on the part of the VFS. Care would also have to be taken to avoid a reference count loop: File points to Inode points to File. Not insurmountable though. The list would be NULL most of the time. If Linux apps start using this feature a lot, then it can be optimized. No. The list could never be NULL. Excuse me? Does Win32 not allow rename of open files? It does, but the internal object name does not change. You cannot create a new file of the old name whilst it is still open internally. Assuming that is the problem, you have a few options I think. You could let handles block rename, except that you might let root override restrictions caused by non-root users. *shiver* You could just ignore this problem and see what, if anything, breaks. I really don't like doing that. It's always an important customer who falls over it. You could lie I suppose, supplying old names as needed. Then you should stick with the current system. Doesn't that strike you as being a hack that will cause you to need _more_ code in the end? No. You'll end up writing a second VFS layer if I'm not mistaken. No I won't. I wasn't really thinking in terms of having a process handles map as a directory full of fd's, more like a flat file with a list in it. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Alexander Viro [EMAIL PROTECTED] wrote: Then these apps are non-portable to other Unices and either get fixed or get rm'd. Period. Definitely. In case you've missed that, Win32 is misdesigned crap. It's one thing to add binary compatibility _if_ it doesn't affect the native stuff, but merging that abortion into the native API Just Is Not Going To Happen. I agree with you on that. I'd quite like a Win32 API to be available, but I wouldn't like it to have too much impact on the main Linux kernel. I presume that you don't have a problem with it implemented in a module for use in accelerating Wine? The longer I'm looking at that thread the more it looks like an attempt to merge incompatible models. Last time that happened we got Missed'em'V and that's going to be _much_ worse. Mixing v7 with CP/M gave DOS. List goes on and on and there is _nothing_ but shit on it. True the two are pretty much incompatible... but I can implement a large amount of the basic Win32 API in kernel space without affecting on the rest of the kernel. I will, however, supply a couple of patches to add useful extra features that are internal to the kernel anyway, and don't affect the userspace API semantics. These include process death notification (which someone else expressed interest in for some other purpose) and some optional hooks to make it faster and easier to use my implementation. Folks, get real - if you want NT you know where to find it. Yes - written on the reverse of my cup mat *grin*. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Mon, 25 Sep 2000, Albert D. Cahalan wrote: > If you'd like to live without all /proc-using tools, much of /sbin, > the X server, inetd, anything that uses sendfile(), and anything > that uses RT-signals for IO events... go right ahead. You can give > up on VFS enhancements too, since anything using them wouldn't be > portable to AIX, Ultrix, or OpenServer. > > Partial list of non-portable system calls for you to abstain from: > > mkdir have fun, because this isn't portable Non-portable to _what_? v2? > sigaction you know what to do... I can live with that. Supported by quite a few Unices. > setreuid Encapsulate unless you want a major PITA maintaining the code. > symlink you can use the v7 filesystem too Same as with sigaction, even wider support. > ioplobvious _Yes_. It's non-portable within Linux, ferchrissake. And yes, hardware-related work should be localized. > clone Can be implemented via rfork(), so that gives *BSD and Plan 9. > setfsuiddidn't Ted come up with this one? And you advocate using it? Wow. > pollcan't use select either Both are remarkably ugly. Yes, it's one of the cases when you may need your own functions encapsulating that mess. > prctl comes from IRIX, not v7 And is ugly as hell, as damn next to everything coming from SGI. > pread SysV, isn't it? Must be bad! I'm yet to see where it is necessary. For all practical purposes can be emulated by lseek()+read()+lseek() and you'ld better provide such emulation anyway if you want to have the thing portable. > sendfilejust some benchmark hack Bingo. Can be implemented via primitives, though. > SCO has some UNIX source that might be more to your > liking than Linux is. Unlikely. GNU userland, as ugly as it is, is less obnoxious than Missed'em'V one. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Alexander Viro writes: > On Mon, 25 Sep 2000, Albert D. Cahalan wrote: >> The list would be NULL most of the time. If Linux apps start >> using this feature a lot, then it can be optimized. > > Then these apps are non-portable to other Unices and either get fixed or > get rm'd. Period. If you'd like to live without all /proc-using tools, much of /sbin, the X server, inetd, anything that uses sendfile(), and anything that uses RT-signals for IO events... go right ahead. You can give up on VFS enhancements too, since anything using them wouldn't be portable to AIX, Ultrix, or OpenServer. Partial list of non-portable system calls for you to abstain from: mkdir have fun, because this isn't portable sigaction you know what to do... setreuid symlink you can use the v7 filesystem too ioplobvious clone setfsuiddidn't Ted come up with this one? pollcan't use select either prctl comes from IRIX, not v7 pread SysV, isn't it? Must be bad! sendfilejust some benchmark hack SCO has some UNIX source that might be more to your liking than Linux is. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Mon, 25 Sep 2000, Albert D. Cahalan wrote: > > * Win32 access/share flags would have to be retained in the file > > struct, and the inode struct would have to maintain a list of these. > > OK. Problem? > > The list would be NULL most of the time. If Linux apps start > using this feature a lot, then it can be optimized. Then these apps are non-portable to other Unices and either get fixed or get rm'd. Period. > > * A file handle's view of the filename shouldn't get changed > > even if the file is renamed whilst open. > > Excuse me? Does Win32 not allow rename of open files? Yes. In case you've missed that, Win32 is misdesigned crap. It's one thing to add binary compatibility _if_ it doesn't affect the native stuff, but merging that abortion into the native API Just Is Not Going To Happen. The longer I'm looking at that thread the more it looks like an attempt to merge incompatible models. Last time that happened we got Missed'em'V and that's going to be _much_ worse. Mixing v7 with CP/M gave DOS. List goes on and on and there is _nothing_ but shit on it. Folks, get real - if you want NT you know where to find it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Howells writes: > I'm still not keen on the idea, though... One of the things I'm trying to > avoid is having to maintain a large patch to the kernel. I've done it before Well, if this isn't worth doing right... Patch size is just something you have to deal with. Hopefully you can get an early-2.5.x merge. > I can see your point... though it could get very heavy on fd's. > There are some advantages to the fd approach: > > * You could use WaitFor*() on ordinary fds. It could use the > internal poll method for non-Win32 fds. Why limit it? If the existing poll method needs extension, do it. > * The /proc/*/fd/ driver could be modified to support Win32 handles, > probably by extending the file_operations or inode_operations struct. > > * The dentry stuff has filename support. > > * Object retension is managed by the VFS. > > * No need for kernel based fd<->handle translation. > > * You could make the Win32 objects appear in the normal UNIX VFS > view of the world by having a new filesystem mounted somewhere > appropriate. > > Also some disadvantages: > > * The VFS is quite heavy on kernel memory: three layers of > structure - file, dentry and inode. The inode structure > being a bit of a monster. That may be, but we deal with it all the time. The VFS code has to be well-optimized and SMP-safe. Besides, many of these Win32 handles will refer to files anyway, won't they? > * The dentry filename support does not handle anonymous files. Sure it does. What do you want, pre-deleted files or filesystems that do not appear anywhere? You can have a filesystem floating around in free space, sort of half-way mounted (no mount point), and filled with deleted files with random hex names. > * The dentry filename support does not handle separate namespaces. By this you mean...? Can you not just apply a prefix? Perhaps you could use the half-way mounted filesystems, with some way to specify the desired filesystem root. > * Can't pass initialisation data to the open routine. Well, that would be generally useful for Linux software. Also useful: an open-read-close operation that doesn't muck around with fd allocation. Maybe hang the data off of a struct stat, so that callers can atomicly get everything. > * Win32 access/share flags would have to be retained in the file > struct, and the inode struct would have to maintain a list of these. OK. Problem? The list would be NULL most of the time. If Linux apps start using this feature a lot, then it can be optimized. > * A file handle's view of the filename shouldn't get changed > even if the file is renamed whilst open. Excuse me? Does Win32 not allow rename of open files? Assuming that is the problem, you have a few options I think. You could let handles block rename, except that you might let root override restrictions caused by non-root users. You could just ignore this problem and see what, if anything, breaks. You could lie I suppose, supplying old names as needed. > And some problems either way: > > * The dentry filename support does not handle wide character names or > case-independent matching. Yeah, that is a problem. Ignore it, so it might go away. :-) Mere ASCII case is no problem, and wide characters can always be translated to UTF-8 to keep the VFS happy. Maybe you can add an alternate matching function for Win32 and MacOS API support. > One other thing: the idea you put forth about looking at > /proc/12345/fd/ could be kept, but as /proc/12345/handles > instead with a non-fd approach. Doesn't that strike you as being a hack that will cause you to need _more_ code in the end? You'll end up writing a second VFS layer if I'm not mistaken. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
"Albert D. Cahalan" <[EMAIL PROTECTED]> wrote: > #define HANDLE_TO_FD(x) ((x)>>2) > #define FD_TO_HANDLE(x) ((x)<<2) (not quite as simple as that since fd 0 is valid and handle 0 is not, but that's a very minor issue.) I'm still not keen on the idea, though... One of the things I'm trying to avoid is having to maintain a large patch to the kernel. I've done it before with the configuration manager I wrote. At the time, there was a new version of the kernel out at least once a week, and I spent nearly all my time porting the patch to the latest kernels. I can see your point... though it could get very heavy on fd's. There are some advantages to the fd approach: * You could use WaitFor*() on ordinary fds. It could use the internal poll method for non-Win32 fds. * The /proc/*/fd/ driver could be modified to support Win32 handles, probably by extending the file_operations or inode_operations struct. * The dentry stuff has filename support. * Object retension is managed by the VFS. * No need for kernel based fd<->handle translation. * You could make the Win32 objects appear in the normal UNIX VFS view of the world by having a new filesystem mounted somewhere appropriate. Also some disadvantages: * The VFS is quite heavy on kernel memory: three layers of structure - file, dentry and inode. The inode structure being a bit of a monster. * The dentry filename support does not handle anonymous files. * The dentry filename support does not handle separate namespaces. * Can't pass initialisation data to the open routine. * Win32 access/share flags would have to be retained in the file struct, and the inode struct would have to maintain a list of these. * A file handle's view of the filename shouldn't get changed even if the file is renamed whilst open. And some problems either way: * The dentry filename support does not handle wide character names or case-independent matching. One other thing: the idea you put forth about looking at /proc/12345/fd/ could be kept, but as /proc/12345/handles instead with a non-fd approach. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
"Albert D. Cahalan" [EMAIL PROTECTED] wrote: #define HANDLE_TO_FD(x) ((x)2) #define FD_TO_HANDLE(x) ((x)2) (not quite as simple as that since fd 0 is valid and handle 0 is not, but that's a very minor issue.) I'm still not keen on the idea, though... One of the things I'm trying to avoid is having to maintain a large patch to the kernel. I've done it before with the configuration manager I wrote. At the time, there was a new version of the kernel out at least once a week, and I spent nearly all my time porting the patch to the latest kernels. I can see your point... though it could get very heavy on fd's. There are some advantages to the fd approach: * You could use WaitFor*() on ordinary fds. It could use the internal poll method for non-Win32 fds. * The /proc/*/fd/ driver could be modified to support Win32 handles, probably by extending the file_operations or inode_operations struct. * The dentry stuff has filename support. * Object retension is managed by the VFS. * No need for kernel based fd-handle translation. * You could make the Win32 objects appear in the normal UNIX VFS view of the world by having a new filesystem mounted somewhere appropriate. Also some disadvantages: * The VFS is quite heavy on kernel memory: three layers of structure - file, dentry and inode. The inode structure being a bit of a monster. * The dentry filename support does not handle anonymous files. * The dentry filename support does not handle separate namespaces. * Can't pass initialisation data to the open routine. * Win32 access/share flags would have to be retained in the file struct, and the inode struct would have to maintain a list of these. * A file handle's view of the filename shouldn't get changed even if the file is renamed whilst open. And some problems either way: * The dentry filename support does not handle wide character names or case-independent matching. One other thing: the idea you put forth about looking at /proc/12345/fd/ could be kept, but as /proc/12345/handles instead with a non-fd approach. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Mon, 25 Sep 2000, Albert D. Cahalan wrote: * Win32 access/share flags would have to be retained in the file struct, and the inode struct would have to maintain a list of these. OK. Problem? The list would be NULL most of the time. If Linux apps start using this feature a lot, then it can be optimized. Then these apps are non-portable to other Unices and either get fixed or get rm'd. Period. * A file handle's view of the filename shouldn't get changed even if the file is renamed whilst open. Excuse me? Does Win32 not allow rename of open files? Yes. In case you've missed that, Win32 is misdesigned crap. It's one thing to add binary compatibility _if_ it doesn't affect the native stuff, but merging that abortion into the native API Just Is Not Going To Happen. The longer I'm looking at that thread the more it looks like an attempt to merge incompatible models. Last time that happened we got Missed'em'V and that's going to be _much_ worse. Mixing v7 with CP/M gave DOS. List goes on and on and there is _nothing_ but shit on it. Folks, get real - if you want NT you know where to find it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Howells writes: I'm still not keen on the idea, though... One of the things I'm trying to avoid is having to maintain a large patch to the kernel. I've done it before Well, if this isn't worth doing right... Patch size is just something you have to deal with. Hopefully you can get an early-2.5.x merge. I can see your point... though it could get very heavy on fd's. There are some advantages to the fd approach: * You could use WaitFor*() on ordinary fds. It could use the internal poll method for non-Win32 fds. Why limit it? If the existing poll method needs extension, do it. * The /proc/*/fd/ driver could be modified to support Win32 handles, probably by extending the file_operations or inode_operations struct. * The dentry stuff has filename support. * Object retension is managed by the VFS. * No need for kernel based fd-handle translation. * You could make the Win32 objects appear in the normal UNIX VFS view of the world by having a new filesystem mounted somewhere appropriate. Also some disadvantages: * The VFS is quite heavy on kernel memory: three layers of structure - file, dentry and inode. The inode structure being a bit of a monster. That may be, but we deal with it all the time. The VFS code has to be well-optimized and SMP-safe. Besides, many of these Win32 handles will refer to files anyway, won't they? * The dentry filename support does not handle anonymous files. Sure it does. What do you want, pre-deleted files or filesystems that do not appear anywhere? You can have a filesystem floating around in free space, sort of half-way mounted (no mount point), and filled with deleted files with random hex names. * The dentry filename support does not handle separate namespaces. By this you mean...? Can you not just apply a prefix? Perhaps you could use the half-way mounted filesystems, with some way to specify the desired filesystem root. * Can't pass initialisation data to the open routine. Well, that would be generally useful for Linux software. Also useful: an open-read-close operation that doesn't muck around with fd allocation. Maybe hang the data off of a struct stat, so that callers can atomicly get everything. * Win32 access/share flags would have to be retained in the file struct, and the inode struct would have to maintain a list of these. OK. Problem? The list would be NULL most of the time. If Linux apps start using this feature a lot, then it can be optimized. * A file handle's view of the filename shouldn't get changed even if the file is renamed whilst open. Excuse me? Does Win32 not allow rename of open files? Assuming that is the problem, you have a few options I think. You could let handles block rename, except that you might let root override restrictions caused by non-root users. You could just ignore this problem and see what, if anything, breaks. You could lie I suppose, supplying old names as needed. And some problems either way: * The dentry filename support does not handle wide character names or case-independent matching. Yeah, that is a problem. Ignore it, so it might go away. :-) Mere ASCII case is no problem, and wide characters can always be translated to UTF-8 to keep the VFS happy. Maybe you can add an alternate matching function for Win32 and MacOS API support. One other thing: the idea you put forth about looking at /proc/12345/fd/ could be kept, but as /proc/12345/handles instead with a non-fd approach. Doesn't that strike you as being a hack that will cause you to need _more_ code in the end? You'll end up writing a second VFS layer if I'm not mistaken. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Alexander Viro writes: On Mon, 25 Sep 2000, Albert D. Cahalan wrote: The list would be NULL most of the time. If Linux apps start using this feature a lot, then it can be optimized. Then these apps are non-portable to other Unices and either get fixed or get rm'd. Period. If you'd like to live without all /proc-using tools, much of /sbin, the X server, inetd, anything that uses sendfile(), and anything that uses RT-signals for IO events... go right ahead. You can give up on VFS enhancements too, since anything using them wouldn't be portable to AIX, Ultrix, or OpenServer. Partial list of non-portable system calls for you to abstain from: mkdir have fun, because this isn't portable sigaction you know what to do... setreuid symlink you can use the v7 filesystem too ioplobvious clone setfsuiddidn't Ted come up with this one? pollcan't use select either prctl comes from IRIX, not v7 pread SysV, isn't it? Must be bad! sendfilejust some benchmark hack SCO has some UNIX source that might be more to your liking than Linux is. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Howells writes: > [EMAIL PROTECTED] (Albert D. Cahalan) wrote: >> In spite of that, it should be considered. It allows this: >> >> $ ls -log /proc/self/fd >> total 0 >> lrwx--1 acahalan 64 Sep 21 09:12 0 -> /dev/pts/4 >> lrwx--1 acahalan 64 Sep 21 09:12 1 -> /dev/pts/4 >> lrwx--1 acahalan 64 Sep 21 09:12 2 -> /dev/pts/4 >> lrwx--1 acahalan 64 Sep 21 09:12 3 -> mutex:[720429] >> lrwx--1 acahalan 64 Sep 21 09:12 4 -> event:[592] >> lr-x--1 acahalan 64 Sep 21 09:12 5 -> /proc/14527/fd > > There's another minor problem with using fd's as handles... Windows expects > the handle number to be a multiple of 4, and sometimes, probably only on rare > occasions, uses the bottom two bits to pass extra information. I was flicking > through the Native API reference last night, and came across a couple of > instances. I don't know whether this ever applies to Win32, though. #define HANDLE_TO_FD(x) ((x)>>2) #define FD_TO_HANDLE(x) ((x)<<2) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
[EMAIL PROTECTED] (Albert D. Cahalan) wrote: > In spite of that, it should be considered. It allows this: > > $ ls -log /proc/self/fd > total 0 > lrwx--1 acahalan 64 Sep 21 09:12 0 -> /dev/pts/4 > lrwx--1 acahalan 64 Sep 21 09:12 1 -> /dev/pts/4 > lrwx--1 acahalan 64 Sep 21 09:12 2 -> /dev/pts/4 > lrwx--1 acahalan 64 Sep 21 09:12 3 -> mutex:[720429] > lrwx--1 acahalan 64 Sep 21 09:12 4 -> event:[592] > lr-x--1 acahalan 64 Sep 21 09:12 5 -> /proc/14527/fd There's another minor problem with using fd's as handles... Windows expects the handle number to be a multiple of 4, and sometimes, probably only on rare occasions, uses the bottom two bits to pass extra information. I was flicking through the Native API reference last night, and came across a couple of instances. I don't know whether this ever applies to Win32, though. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
[EMAIL PROTECTED] (Albert D. Cahalan) wrote: In spite of that, it should be considered. It allows this: $ ls -log /proc/self/fd total 0 lrwx--1 acahalan 64 Sep 21 09:12 0 - /dev/pts/4 lrwx--1 acahalan 64 Sep 21 09:12 1 - /dev/pts/4 lrwx--1 acahalan 64 Sep 21 09:12 2 - /dev/pts/4 lrwx--1 acahalan 64 Sep 21 09:12 3 - mutex:[720429] lrwx--1 acahalan 64 Sep 21 09:12 4 - event:[592] lr-x--1 acahalan 64 Sep 21 09:12 5 - /proc/14527/fd There's another minor problem with using fd's as handles... Windows expects the handle number to be a multiple of 4, and sometimes, probably only on rare occasions, uses the bottom two bits to pass extra information. I was flicking through the Native API reference last night, and came across a couple of instances. I don't know whether this ever applies to Win32, though. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Howells writes: [EMAIL PROTECTED] (Albert D. Cahalan) wrote: In spite of that, it should be considered. It allows this: $ ls -log /proc/self/fd total 0 lrwx--1 acahalan 64 Sep 21 09:12 0 - /dev/pts/4 lrwx--1 acahalan 64 Sep 21 09:12 1 - /dev/pts/4 lrwx--1 acahalan 64 Sep 21 09:12 2 - /dev/pts/4 lrwx--1 acahalan 64 Sep 21 09:12 3 - mutex:[720429] lrwx--1 acahalan 64 Sep 21 09:12 4 - event:[592] lr-x--1 acahalan 64 Sep 21 09:12 5 - /proc/14527/fd There's another minor problem with using fd's as handles... Windows expects the handle number to be a multiple of 4, and sometimes, probably only on rare occasions, uses the bottom two bits to pass extra information. I was flicking through the Native API reference last night, and came across a couple of instances. I don't know whether this ever applies to Win32, though. #define HANDLE_TO_FD(x) ((x)2) #define FD_TO_HANDLE(x) ((x)2) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
"Albert D. Cahalan" <[EMAIL PROTECTED]> wrote: > In spite of that, it should be considered. It allows this: > > $ ls -log /proc/self/fd > total 0 > lrwx--1 acahalan 64 Sep 21 09:12 0 -> /dev/pts/4 > lrwx--1 acahalan 64 Sep 21 09:12 1 -> /dev/pts/4 > lrwx--1 acahalan 64 Sep 21 09:12 2 -> /dev/pts/4 > lrwx--1 acahalan 64 Sep 21 09:12 3 -> mutex:[720429] > lrwx--1 acahalan 64 Sep 21 09:12 4 -> event:[592] > lr-x--1 acahalan 64 Sep 21 09:12 5 -> /proc/14527/fd Looks nice, I know, but it may mean file handles are indirect, in that you have: struct file->struct dentry->struct inode->struct winefile->struct file->... if you can't store all the extra wine attributes on the struct file. It also means that the inode or the dentry has to maintain a list of attached file's, which I don't think it does at the moment. > >> Any information not in kernel structure is Wine specific anyway, so > >> should be separate > > It goes into the kernel structure, so that it won't be Wine-specific. > SGI has already done this so that Samba would interact properly with > regular UNIX software and the NFS server. > > (one might support SGI's API for this) Hmmm... worth investigating. I take it that this was only done for IRIX, not Linux. > Yep, share bits definitely belong in the kernel. How else could > you properly protect against regular (clueless) Linux software? Probably do... > We already have 3 ways to do file locking, so this is only 33% more. 66%... Don't forget LockFile/UnlockFile. These work very similarly to fcntl, I think, but demand mandatory locking. > Now THAT would be a disaster. Linux software ought to be able to rely > on having these features available. I agree, but does Linus? > Modules are very bad for this. Probably, but unless the code goes into the kernel proper, patch maintainance can be a real nightmare. The greater the amount of kernel actually changed by a patch, the worse it is. > Named? That means you use the VFS. Not necessarily. For file handles, you probably should (unless you want drive-letter mappings to occur in the kernel - yuk), but the other things are effectively in separate namespaces. >> Don't use it then... it'll not be mandatory. Wine has also to support OS's >> that can't or won't add Win32 support in the kernel. You misunderstand me... _Using_ this API will not be mandatory, whether or not it exists in the kernel proper. > See a pattern here? System calls are not supposed to be modular. knfsd? But I agree, really. But what is the likelyhood? > We shouldn't have calls that appear and disappear on a whim. True... that smacks of MS policy:-) > Binary compatibility requires that system calls be available on > all Linux systems. Also true. You should be able to compile the module I currently have on all Linux systems. Unfortunately, I can't test this at the moment. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Howells writes: > Waldek Hebisch <[EMAIL PROTECTED]> wrote: > I think we have a misunderstanding here... I meant that using the VFS > structures for Win32 objects like mutexes, semaphores and events is > massive overkill, and uses a great deal of unnecessary memory. In spite of that, it should be considered. It allows this: $ ls -log /proc/self/fd total 0 lrwx--1 acahalan 64 Sep 21 09:12 0 -> /dev/pts/4 lrwx--1 acahalan 64 Sep 21 09:12 1 -> /dev/pts/4 lrwx--1 acahalan 64 Sep 21 09:12 2 -> /dev/pts/4 lrwx--1 acahalan 64 Sep 21 09:12 3 -> mutex:[720429] lrwx--1 acahalan 64 Sep 21 09:12 4 -> event:[592] lr-x--1 acahalan 64 Sep 21 09:12 5 -> /proc/14527/fd Alternately, it allows this: $ ls -log /proc/self/fd total 0 lrwx--1 acahalan 64 Sep 21 09:12 0 -> /dev/pts/4 lrwx--1 acahalan 64 Sep 21 09:12 1 -> /dev/pts/4 lrwx--1 acahalan 64 Sep 21 09:12 2 -> /dev/pts/4 lrwx--1 acahalan 64 Sep 21 09:12 3 -> /mutex/720429 lrwx--1 acahalan 64 Sep 21 09:12 4 -> /event/592 lr-x--1 acahalan 64 Sep 21 09:12 5 -> /proc/14527/fd $ ls -log /mutex total 0 mrw--w1 acahalan0 Sep 21 09:33 720429 mrw--w1 acahalan0 Sep 18 19:33 2852 mrw---1 acahalan0 Sep 21 09:33 53245325 mrw--w1 acahalan0 Sep 21 09:33 88234 $ ls -log /event total 0 erw---1 acahalan0 Sep 21 09:33 592 >>> (3) Linux file structures do not hold enough information to support >>> CreateFile (access & sharing interactions). >> >> Any information not in kernel structure is Wine specific anyway, so >> should be separate It goes into the kernel structure, so that it won't be Wine-specific. SGI has already done this so that Samba would interact properly with regular UNIX software and the NFS server. (one might support SGI's API for this) > What I meant on the CreateFile() front is that this function takes > an access bitmask and a share bitmask which interact with other > CreateFile()'s and some other functions. For instance, if two > separate CreateFile()'s are issued on a file then the second is > rejected if it's share mask excludes the first's access mask or > if the first's share mask excludes the second's access mask. Yep, share bits definitely belong in the kernel. How else could you properly protect against regular (clueless) Linux software? >> However, Unix has quite a lot of mechanisms for interprocess >> comunication: signals, shared memory, SYSV IPC semaphores and messages, >> sockets, pipes. A lot of kernel structers and code is just to make >> this work efficiently and relaiably. Putting in the kernel subsystem >> which to large degree has the same functionality (but with incompatible >> interface) seems like a recipe for disaster (small is the project >> dies, big is it makes its way to the kernel). We already have 3 ways to do file locking, so this is only 33% more. > Why should it be a disaster? It can just be kept as a module > that is loaded to accelerate Wine. Now THAT would be a disaster. Linux software ought to be able to rely on having these features available. Modules are very bad for this. Look, we don't have flock() in a module. >> However, I would rather belive that they already exists. As long >> as I understand the main problem is Wine I/O performance. The other >> problem is to have efficient mutexes. I expect SYSV stuff to be >> reasonably efficient, and very fast mutexes may be implemented >> (almost) in user space using ix86 assembly. With shared memory and >> fast mutexes it should be possible to move I/O to client side even >> in multithreading programs. > > That entails all sorts of other problems... On Win32, a lot of > these objects are named... That means you have to have some sort > of atomic-access name table in shared memory. Named? That means you use the VFS. >> I understand that Wine has good reasons to use W32 interfaces internally, >> but pushing them to Linux kernel seems bad for me. > > Don't use it then... it'll not be mandatory. Wine has also to support OS's > that can't or won't add Win32 support in the kernel. The sendfile() call is mandatory. The real-time schedular and signals are mandatory. The clone() call is mandatory. The prctl() call is mandatory. See a pattern here? System calls are not supposed to be modular. We shouldn't have calls that appear and disappear on a whim. Binary compatibility requires that system calls be available on all Linux systems. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Waldek Hebisch <[EMAIL PROTECTED]> wrote: > > (2) the struct file+struct dentry+struct inode complex is incredibly heavy > > for most of what I want to do (though does have advantages); > Well, all (ok most) of this complexity is to support Unix semantics. > Adding structures with different sematics will (IMHO) mean huge > increase in complexity (if interactions are handled correctly) and > invites bugs I think we have a misunderstanding here... I meant that using the VFS structures for Win32 objects like mutexes, semaphores and events is massive overkill, and uses a great deal of unnecessary memory. What I did was to have a separate structure for representing Win32 objects that is kept totally separate from the rest of the Linux kernel VFS stuff. It is also a lot smaller than the three-layer VFS system, and only has the bits that are necessary for implementing Win32 object handling and waiting. Note though, in the case of a file handle, this Win32 object contains a pointer to a struct file, but this is the only way to gain access to the VFS through this system, and it still isolates the VFS effectively. > > (3) Linux file structures do not hold enough information to support > > CreateFile (access & sharing interactions). > Any information not in kernel structure is Wine specific anyway, so > should be separate Definitely, and I've kept it so. What I meant on the CreateFile() front is that this function takes an access bitmask and a share bitmask which interact with other CreateFile()'s and some other functions. For instance, if two separate CreateFile()'s are issued on a file then the second is rejected if it's share mask excludes the first's access mask or if the first's share mask excludes the second's access mask. It gets a bit more complex as more CreateFile()'s succeed on a particular file, since the access flags are additive, and the share masks are subtractive. The point, though, is that this information must be retained to reproduce the semantics of the relevant functions. Wine keeps it in the wineserver process, and uses RPC over sockets to get to it. > Everybody sometimes gets an idea which looks very promising (and yes, I > too like my ideas more then the other). > However, Unix has quite a lot of mechanisms for interprocess > comunication: signals, shared memory, SYSV IPC semaphores and messages, > sockets, pipes. A lot of kernel structers and code is just to make > this work efficiently and relaiably. Putting in the kernel subsystem > which to large degree has the same functionality (but with incompatible > interface) seems like a recipe for disaster (small is the project > dies, big is it makes its way to the kernel). Why should it be a disaster? It can just be kept as a module that is loaded to accelerate Wine. > On construtive grounds: I think that nobody would object putting > into kernel few primitives if they are critical for Wine performance. With what API? > However, I would rather belive that they already exists. As long > as I understand the main problem is Wine I/O performance. The other > problem is to have efficient mutexes. I expect SYSV stuff to be > reasonably efficient, and very fast mutexes may be implemented > (almost) in user space using ix86 assembly. With shared memory and > fast mutexes it should be possible to move I/O to client side even > in multithreading programs. That entails all sorts of other problems... On Win32, a lot of these objects are named... That means you have to have some sort of atomic-access name table in shared memory. And you also have to implement WaitFor*() without doing a tight polling loop (whilst you could use signals, that is slow). Also you have to be able to do release-on-death management (how to catch SIGKILL?). The thing about the kernel is that it has pre-existing services to solve these problems: locks, wait-queues and atomic counters. You can solve _most_ of these problems in userspace without a separate server process, but at the cost of a great deal of extra complexity and at the cost of not being able to provide the full behaviour. > I think that Linux programmers rather than new syscalls would like > Wine to provide ability to handle metafiles (it happened), OLE > streams or W32 widgets. So, from such a point of view us much > as possible interfaces should be Unix-like, and W32 interfaces > used only when needed. Or maybe, they'd like both to be available. The two aren't mutually exclusive. > I understand that Wine has good reasons to use W32 interfaces internally, > but pushing them to Linux kernel seems bad for me. Don't use it then... it'll not be mandatory. Wine has also to support OS's that can't or won't add Win32 support in the kernel. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Waldek Hebisch [EMAIL PROTECTED] wrote: (2) the struct file+struct dentry+struct inode complex is incredibly heavy for most of what I want to do (though does have advantages); Well, all (ok most) of this complexity is to support Unix semantics. Adding structures with different sematics will (IMHO) mean huge increase in complexity (if interactions are handled correctly) and invites bugs I think we have a misunderstanding here... I meant that using the VFS structures for Win32 objects like mutexes, semaphores and events is massive overkill, and uses a great deal of unnecessary memory. What I did was to have a separate structure for representing Win32 objects that is kept totally separate from the rest of the Linux kernel VFS stuff. It is also a lot smaller than the three-layer VFS system, and only has the bits that are necessary for implementing Win32 object handling and waiting. Note though, in the case of a file handle, this Win32 object contains a pointer to a struct file, but this is the only way to gain access to the VFS through this system, and it still isolates the VFS effectively. (3) Linux file structures do not hold enough information to support CreateFile (access sharing interactions). Any information not in kernel structure is Wine specific anyway, so should be separate Definitely, and I've kept it so. What I meant on the CreateFile() front is that this function takes an access bitmask and a share bitmask which interact with other CreateFile()'s and some other functions. For instance, if two separate CreateFile()'s are issued on a file then the second is rejected if it's share mask excludes the first's access mask or if the first's share mask excludes the second's access mask. It gets a bit more complex as more CreateFile()'s succeed on a particular file, since the access flags are additive, and the share masks are subtractive. The point, though, is that this information must be retained to reproduce the semantics of the relevant functions. Wine keeps it in the wineserver process, and uses RPC over sockets to get to it. Everybody sometimes gets an idea which looks very promising (and yes, I too like my ideas more then the other). However, Unix has quite a lot of mechanisms for interprocess comunication: signals, shared memory, SYSV IPC semaphores and messages, sockets, pipes. A lot of kernel structers and code is just to make this work efficiently and relaiably. Putting in the kernel subsystem which to large degree has the same functionality (but with incompatible interface) seems like a recipe for disaster (small is the project dies, big is it makes its way to the kernel). Why should it be a disaster? It can just be kept as a module that is loaded to accelerate Wine. On construtive grounds: I think that nobody would object putting into kernel few primitives if they are critical for Wine performance. With what API? However, I would rather belive that they already exists. As long as I understand the main problem is Wine I/O performance. The other problem is to have efficient mutexes. I expect SYSV stuff to be reasonably efficient, and very fast mutexes may be implemented (almost) in user space using ix86 assembly. With shared memory and fast mutexes it should be possible to move I/O to client side even in multithreading programs. That entails all sorts of other problems... On Win32, a lot of these objects are named... That means you have to have some sort of atomic-access name table in shared memory. And you also have to implement WaitFor*() without doing a tight polling loop (whilst you could use signals, that is slow). Also you have to be able to do release-on-death management (how to catch SIGKILL?). The thing about the kernel is that it has pre-existing services to solve these problems: locks, wait-queues and atomic counters. You can solve _most_ of these problems in userspace without a separate server process, but at the cost of a great deal of extra complexity and at the cost of not being able to provide the full behaviour. I think that Linux programmers rather than new syscalls would like Wine to provide ability to handle metafiles (it happened), OLE streams or W32 widgets. So, from such a point of view us much as possible interfaces should be Unix-like, and W32 interfaces used only when needed. Or maybe, they'd like both to be available. The two aren't mutually exclusive. I understand that Wine has good reasons to use W32 interfaces internally, but pushing them to Linux kernel seems bad for me. Don't use it then... it'll not be mandatory. Wine has also to support OS's that can't or won't add Win32 support in the kernel. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
"Albert D. Cahalan" [EMAIL PROTECTED] wrote: In spite of that, it should be considered. It allows this: $ ls -log /proc/self/fd total 0 lrwx--1 acahalan 64 Sep 21 09:12 0 - /dev/pts/4 lrwx--1 acahalan 64 Sep 21 09:12 1 - /dev/pts/4 lrwx--1 acahalan 64 Sep 21 09:12 2 - /dev/pts/4 lrwx--1 acahalan 64 Sep 21 09:12 3 - mutex:[720429] lrwx--1 acahalan 64 Sep 21 09:12 4 - event:[592] lr-x--1 acahalan 64 Sep 21 09:12 5 - /proc/14527/fd Looks nice, I know, but it may mean file handles are indirect, in that you have: struct file-struct dentry-struct inode-struct winefile-struct file-... if you can't store all the extra wine attributes on the struct file. It also means that the inode or the dentry has to maintain a list of attached file's, which I don't think it does at the moment. Any information not in kernel structure is Wine specific anyway, so should be separate It goes into the kernel structure, so that it won't be Wine-specific. SGI has already done this so that Samba would interact properly with regular UNIX software and the NFS server. (one might support SGI's API for this) Hmmm... worth investigating. I take it that this was only done for IRIX, not Linux. Yep, share bits definitely belong in the kernel. How else could you properly protect against regular (clueless) Linux software? Probably do... We already have 3 ways to do file locking, so this is only 33% more. 66%... Don't forget LockFile/UnlockFile. These work very similarly to fcntl, I think, but demand mandatory locking. Now THAT would be a disaster. Linux software ought to be able to rely on having these features available. I agree, but does Linus? Modules are very bad for this. Probably, but unless the code goes into the kernel proper, patch maintainance can be a real nightmare. The greater the amount of kernel actually changed by a patch, the worse it is. Named? That means you use the VFS. Not necessarily. For file handles, you probably should (unless you want drive-letter mappings to occur in the kernel - yuk), but the other things are effectively in separate namespaces. Don't use it then... it'll not be mandatory. Wine has also to support OS's that can't or won't add Win32 support in the kernel. You misunderstand me... _Using_ this API will not be mandatory, whether or not it exists in the kernel proper. See a pattern here? System calls are not supposed to be modular. knfsd? But I agree, really. But what is the likelyhood? We shouldn't have calls that appear and disappear on a whim. True... that smacks of MS policy:-) Binary compatibility requires that system calls be available on all Linux systems. Also true. You should be able to compile the module I currently have on all Linux systems. Unfortunately, I can't test this at the moment. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
> Reiserfs would make a fine registry. Interesting idea... Have a Linux-style registry hive file mounted as a reiserfs filesystem. However, I'd prefer to be able to use Windows-style registry hive files if possible. > > (3) Linux file structures do not hold enough information to support > > CreateFile (access & sharing interactions). > > Didn't IRIX add the access & sharing support for Samba to use? > This looks like a generally useful feature. I presume you mean SGI added it to IRIX? As for generally useful... possibly. The sys_open() and sys_unlink() functions could be modified to make use of it if it was stored on the inode. You could then use sys_CreateFileA() to actually use it fully. However, it won't work over NFS... David Howells
Re: [RFC] Wine speedup through kernel module
David Howells writes: > Daniel Pittman <[EMAIL PROTECTED]> wrote: >>> Thirdly, registry functions should issue system handles, as is done on >>> Windows. If system handles move into the kernel, then registry handles >>> should do too. This also means registry change notifications can be >>> implemented by system handles that WaitFor*() functions can deal with. >> >> That, however, is a convincing reason. > > And that's why I wanted a kernel interface to the registry stuff, > for which the RPC mechanism was added. Reiserfs would make a fine registry. > (3) Linux file structures do not hold enough information to support > CreateFile (access & sharing interactions). Didn't IRIX add the access & sharing support for Samba to use? This looks like a generally useful feature. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Daniel Pittman <[EMAIL PROTECTED]> wrote: > *blink* I confess that I can't see that much of a requirement for the > ptrace stuff, but I take your word for it. :) I was under the impression that the wineserver used ptrace() to retrieve argument data to requests such as CreateFile(), but thinking about it, that can't be so, since that'd mean you couldn't strace a wine program, which you can. It must instead pass all the argument data either by socket or by shared memory (I'm not sure which offhand). It does, however, (at least, I think it does), use this for debugging support, but that's a special case. > > Secondly, the client (wine) just has to issue a syscall that looks > > exactly like a Win32 registry function, how it is handled is hidden by > > the kernel. > > Not really something that I would have thought was needed - > specifically, the userspace libraries that the process was dynamic > linked to would have been the place to do that, I thought. I suppose this is more of an implementation detail, but it's primarily why I added an RPC mechanism. > > Thirdly, registry functions should issue system handles, as is done on > > Windows. If system handles move into the kernel, then registry handles > > should do too. This also means registry change notifications can be > > implemented by system handles that WaitFor*() functions can deal with. > > That, however, is a convincing reason. And that's why I wanted a kernel interface to the registry stuff, for which the RPC mechanism was added. > IIRC there are not any waitable GHI objects, precisely because under > Win32 the GDI is a userspace library that does most of the magic > internally and then, finally, requests that the server does something. > > Like sockets, the GDI isn't actually a Win32 kernel thing, it's a Win32 > userspace wrapper that makes the minimalist kernel support more > palatable. However, I could make a Window a waitable GDI object... implementing GetMessage() as Wait, GetAsync. What I'd need to do is make it possible for the RPC server to create signallable handles of effectively user-defined type that can be issued by and passed through RPC calls. Hmmm... I'll have to think about that, but I'll probably have to do something along these lines to support registry change notifications. > > Now there's an idea... Have the local X server as an RPC server, > > handling wine GDI calls directly *grin*. Then I could hide all the GDI > > stuff behind syscall stubs in the same way. This would allow me to > > implement a lot of the NT Native API. > > Well, that's a point of view thing. The native NT API isn't anything > beyond kernel32, as such. Certainly, the GDI isn't part of the core API > and, in some cases, MicroSoft do release or use the NT core without the > GUI system, at the least. But it is there. I think it may use WinStation handles somehow, but I don't know for sure without a bit of disassembly work. > Anyhow, I am hardly an expert on the area, but... I would have avoided > putting stubs into the kernel anywhere that it was possible and used the > userspace dynamic Win32 libraries to do most of the work. It depends on what you want... What I'd like is basically a range of Win32 system handles that map to (or apparently map to) kernel services. I'd also like these to be available for ordinary Linux programs to play with if they want to. However, I think I might be able to see what you mean... I could implement an RPC server, say, that has one exported operation: do registry op. Then have all the registry operations mapped down by a userspace library to the RPC invocation call to a single operation on that particular server. > OTOH, I would also have implemented the WaitFor* set as a wrapper over > select, with the kernel module providing suitable file descriptors for > adding to the set that you waited for. This is one of the things I was trying to avoid: (1) select and poll do not implement the entire range of things you can do with WaitForMultipleObjects; (2) the struct file+struct dentry+struct inode complex is incredibly heavy for most of what I want to do (though does have advantages); (3) Linux file structures do not hold enough information to support CreateFile (access & sharing interactions). > We have fairly different views on how this stuff would hang together > and, in all likelyhood, mine are based on incorrect assumptions. :) True... Isn't it nice when you can provide what API's you want rather than having to make do with whatever is dictated to you. Yes... I'm implementing some of the Windows system APIs because I'd like to have that functionality available under Linux running as fast as possible, not because it's the only one worth using:-) David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Daniel Pittman [EMAIL PROTECTED] wrote: *blink* I confess that I can't see that much of a requirement for the ptrace stuff, but I take your word for it. :) I was under the impression that the wineserver used ptrace() to retrieve argument data to requests such as CreateFile(), but thinking about it, that can't be so, since that'd mean you couldn't strace a wine program, which you can. It must instead pass all the argument data either by socket or by shared memory (I'm not sure which offhand). It does, however, (at least, I think it does), use this for debugging support, but that's a special case. Secondly, the client (wine) just has to issue a syscall that looks exactly like a Win32 registry function, how it is handled is hidden by the kernel. Not really something that I would have thought was needed - specifically, the userspace libraries that the process was dynamic linked to would have been the place to do that, I thought. I suppose this is more of an implementation detail, but it's primarily why I added an RPC mechanism. Thirdly, registry functions should issue system handles, as is done on Windows. If system handles move into the kernel, then registry handles should do too. This also means registry change notifications can be implemented by system handles that WaitFor*() functions can deal with. That, however, is a convincing reason. And that's why I wanted a kernel interface to the registry stuff, for which the RPC mechanism was added. IIRC there are not any waitable GHI objects, precisely because under Win32 the GDI is a userspace library that does most of the magic internally and then, finally, requests that the server does something. Like sockets, the GDI isn't actually a Win32 kernel thing, it's a Win32 userspace wrapper that makes the minimalist kernel support more palatable. However, I could make a Window a waitable GDI object... implementing GetMessage() as Wait, GetAsync. What I'd need to do is make it possible for the RPC server to create signallable handles of effectively user-defined type that can be issued by and passed through RPC calls. Hmmm... I'll have to think about that, but I'll probably have to do something along these lines to support registry change notifications. Now there's an idea... Have the local X server as an RPC server, handling wine GDI calls directly *grin*. Then I could hide all the GDI stuff behind syscall stubs in the same way. This would allow me to implement a lot of the NT Native API. Well, that's a point of view thing. The native NT API isn't anything beyond kernel32, as such. Certainly, the GDI isn't part of the core API and, in some cases, MicroSoft do release or use the NT core without the GUI system, at the least. But it is there. I think it may use WinStation handles somehow, but I don't know for sure without a bit of disassembly work. Anyhow, I am hardly an expert on the area, but... I would have avoided putting stubs into the kernel anywhere that it was possible and used the userspace dynamic Win32 libraries to do most of the work. It depends on what you want... What I'd like is basically a range of Win32 system handles that map to (or apparently map to) kernel services. I'd also like these to be available for ordinary Linux programs to play with if they want to. However, I think I might be able to see what you mean... I could implement an RPC server, say, that has one exported operation: do registry op. Then have all the registry operations mapped down by a userspace library to the RPC invocation call to a single operation on that particular server. OTOH, I would also have implemented the WaitFor* set as a wrapper over select, with the kernel module providing suitable file descriptors for adding to the set that you waited for. This is one of the things I was trying to avoid: (1) select and poll do not implement the entire range of things you can do with WaitForMultipleObjects; (2) the struct file+struct dentry+struct inode complex is incredibly heavy for most of what I want to do (though does have advantages); (3) Linux file structures do not hold enough information to support CreateFile (access sharing interactions). We have fairly different views on how this stuff would hang together and, in all likelyhood, mine are based on incorrect assumptions. :) True... Isn't it nice when you can provide what API's you want rather than having to make do with whatever is dictated to you. Yes... I'm implementing some of the Windows system APIs because I'd like to have that functionality available under Linux running as fast as possible, not because it's the only one worth using:-) David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Reiserfs would make a fine registry. Interesting idea... Have a Linux-style registry hive file mounted as a reiserfs filesystem. However, I'd prefer to be able to use Windows-style registry hive files if possible. (3) Linux file structures do not hold enough information to support CreateFile (access sharing interactions). Didn't IRIX add the access sharing support for Samba to use? This looks like a generally useful feature. I presume you mean SGI added it to IRIX? As for generally useful... possibly. The sys_open() and sys_unlink() functions could be modified to make use of it if it was stored on the inode. You could then use sys_CreateFileA() to actually use it fully. However, it won't work over NFS... David Howells
Re: [RFC] Wine speedup through kernel module
David Howells writes: Daniel Pittman [EMAIL PROTECTED] wrote: Thirdly, registry functions should issue system handles, as is done on Windows. If system handles move into the kernel, then registry handles should do too. This also means registry change notifications can be implemented by system handles that WaitFor*() functions can deal with. That, however, is a convincing reason. And that's why I wanted a kernel interface to the registry stuff, for which the RPC mechanism was added. Reiserfs would make a fine registry. (3) Linux file structures do not hold enough information to support CreateFile (access sharing interactions). Didn't IRIX add the access sharing support for Samba to use? This looks like a generally useful feature. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Daniel Pittman <[EMAIL PROTECTED]> wrote: > Hrm. It would seem more sensible to me that the registry, like the GDI, > live outside the kernel. This would have some cost in terms of > performance, I admit, but I don't think it's significant enough to care. > > This is, I confess, based on my personal experience with Win32 > development and may not represent the real state of affairs for all > developers. > > Having registry access be performance critical or for large data is also > against the MicroSoft best practice for software, which makes the costs > lower - no multiple calls to ship large quantities of data. :) > > Anyway, why did you see the need for the registry stubs in this case, if > I may ask? Firstly, in wine the registry is handled by the wineserver process. This means it can be shared between all the wine processes running for a particular used. So when wine wants to access the registry, it has to do an RPC call to the wineserver (sending a request across a UNIX socket and then, I think, a bit of ptrace()'ing to get at the data). This provides a hopefully more suitable RPC mechanism. Secondly, the client (wine) just has to issue a syscall that looks exactly like a Win32 registry function, how it is handled is hidden by the kernel. Thirdly, registry functions should issue system handles, as is done on Windows. If system handles move into the kernel, then registry handles should do too. This also means registry change notifications can be implemented by system handles that WaitFor*() functions can deal with. > Well... wont the GDI calls be RPC anyway - specifically, across the X11 > pipe? Yes, but if I implement them to go to a GDI server, which then talks X11 out the back, that's two lots of RPC calls. However, what I said about system handles and the registry, may also apply to GDI objects. > In any case, I would have expected (personally, from assumptions) that > the GDI would live inside the process space and pay the same cost as > existing X11 applications to do it's display. Yes, that is my current plan. > I can't see any sensible reason for implementing anything extra in the > kernel to support it. Now, adding an X11 protocol extension to make some > of the Win32 stuff work better... Now there's an idea... Have the local X server as an RPC server, handling wine GDI calls directly *grin*. Then I could hide all the GDI stuff behind syscall stubs in the same way. This would allow me to implement a lot of the NT Native API. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Bernd Eckenfels <[EMAIL PROTECTED]> wrote: > > * file-change notification > this is interesting for other stuff too, i think irix has an interface for > that, i think its an ioctl? Someone did a file-change notification patch for Linux. I'm not sure exactly what became of it, but it'd be nice to be able to build on top of it. > > * unicode string handling/conversion (steal/share from NTFS) > are you sure this needs to be done in the kernel? if you wat to steal the > sourcecode of the ntfs driver do it, but why would u wat to share object > code for that? Implementation of Win32 wide-character functions and NT Native API calls would require such things. And if I can share them with other bits of the kernel (there's more than just NTFS - smbfs, msdosfs, iso9660), then I can possibly get away with implementing less myself, and bloating the kernel less. > > * simple RPC mechanism for building certain services in userspace > what is that? message passing? in kernel space? Not quite, though it could be used for that... It allows a client to give a server access to parts of its address space, so that the server can provide certain services. The main use I'm thinking of is having the kernelspace stubs of the registry functions transparently invoke RPC requests in a userspace registry server. > > (2) A partial basic Win32 implementation (modulable): > > > * basic Win32 syscalls, eg: CreateMutexA/W > > * _no_ GDI calls > > actuelly kCGI is there? kCGI? What's that? I suppose GDI calls _could_ be done as RPC requests, similar to how I'm intending to do registry calls, but that would incur major overheads as MS found between NT3.51 and NT4, hence why they moved the GDI implementation from CSRSS.EXE into the kernel. However, I was thinking more along the lines of GDI being implemented in userspace by the client process, eg: wine. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Bernd Eckenfels [EMAIL PROTECTED] wrote: * file-change notification this is interesting for other stuff too, i think irix has an interface for that, i think its an ioctl? Someone did a file-change notification patch for Linux. I'm not sure exactly what became of it, but it'd be nice to be able to build on top of it. * unicode string handling/conversion (steal/share from NTFS) are you sure this needs to be done in the kernel? if you wat to steal the sourcecode of the ntfs driver do it, but why would u wat to share object code for that? Implementation of Win32 wide-character functions and NT Native API calls would require such things. And if I can share them with other bits of the kernel (there's more than just NTFS - smbfs, msdosfs, iso9660), then I can possibly get away with implementing less myself, and bloating the kernel less. * simple RPC mechanism for building certain services in userspace what is that? message passing? in kernel space? Not quite, though it could be used for that... It allows a client to give a server access to parts of its address space, so that the server can provide certain services. The main use I'm thinking of is having the kernelspace stubs of the registry functions transparently invoke RPC requests in a userspace registry server. (2) A partial basic Win32 implementation (modulable): * basic Win32 syscalls, eg: CreateMutexA/W * _no_ GDI calls actuelly kCGI is there? kCGI? What's that? I suppose GDI calls _could_ be done as RPC requests, similar to how I'm intending to do registry calls, but that would incur major overheads as MS found between NT3.51 and NT4, hence why they moved the GDI implementation from CSRSS.EXE into the kernel. However, I was thinking more along the lines of GDI being implemented in userspace by the client process, eg: wine. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Daniel Pittman [EMAIL PROTECTED] wrote: Hrm. It would seem more sensible to me that the registry, like the GDI, live outside the kernel. This would have some cost in terms of performance, I admit, but I don't think it's significant enough to care. This is, I confess, based on my personal experience with Win32 development and may not represent the real state of affairs for all developers. Having registry access be performance critical or for large data is also against the MicroSoft best practice for software, which makes the costs lower - no multiple calls to ship large quantities of data. :) Anyway, why did you see the need for the registry stubs in this case, if I may ask? Firstly, in wine the registry is handled by the wineserver process. This means it can be shared between all the wine processes running for a particular used. So when wine wants to access the registry, it has to do an RPC call to the wineserver (sending a request across a UNIX socket and then, I think, a bit of ptrace()'ing to get at the data). This provides a hopefully more suitable RPC mechanism. Secondly, the client (wine) just has to issue a syscall that looks exactly like a Win32 registry function, how it is handled is hidden by the kernel. Thirdly, registry functions should issue system handles, as is done on Windows. If system handles move into the kernel, then registry handles should do too. This also means registry change notifications can be implemented by system handles that WaitFor*() functions can deal with. Well... wont the GDI calls be RPC anyway - specifically, across the X11 pipe? Yes, but if I implement them to go to a GDI server, which then talks X11 out the back, that's two lots of RPC calls. However, what I said about system handles and the registry, may also apply to GDI objects. In any case, I would have expected (personally, from assumptions) that the GDI would live inside the process space and pay the same cost as existing X11 applications to do it's display. Yes, that is my current plan. I can't see any sensible reason for implementing anything extra in the kernel to support it. Now, adding an X11 protocol extension to make some of the Win32 stuff work better... Now there's an idea... Have the local X server as an RPC server, handling wine GDI calls directly *grin*. Then I could hide all the GDI stuff behind syscall stubs in the same way. This would allow me to implement a lot of the NT Native API. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
In article <[EMAIL PROTECTED]> you wrote: > (1) An in-kernel resident lump, providing very basic services: > * file-change notification this is interesting for other stuff too, i think irix has an interface for that, i think its an ioctl? > * unicode string handling/conversion (steal/share from NTFS) are you sure this needs to be done in the kernel? if you wat to steal the sourcecode of the ntfs driver do it, but why would u wat to share object code for that? > * simple RPC mechanism for building certain services in userspace what is that? message passing? in kernel space? > (2) A partial basic Win32 implementation (modulable): > * basic Win32 syscalls, eg: CreateMutexA/W > * _no_ GDI calls actuelly kCGI is there? Greetings Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
> > At the moment, the Win32 syscalls I implement require an fd to be > > attached to a particular proc file. This fd holds the Win32 handle map. > > Huh? Each process needs a handle map... To avoid playing with the task structure, fork, exec, exit, signals, etc., I used an fd attached to a proc file to keep track of the handle map (it gives me reference counting, module tracking, and auto-cleanup on process death). The handle map page is just attached to the private data pointer on the struct file. It was just convenient for starting the whole thing off. > > There are other ways to make sure the module doesn't go away, for > > instance using personalities, but I still need to maintain the > > refcount on the handle map fd. > > Please don't mess with personalities. I intend to use any useful > Win32 or NT-native features in Linux software. Personalities > would make these calls only useful for Wine. Agreed. > If a Win32 handle can be though of as a file descripter, > then just do that. You can invent new file types and new > filesystems as needed. These are available: > > 0x3000 003 > 0x5000 005 > 0x7000 007 > 0x9000 011 > 0xb000 013 I was trying to avoid using file/inode/dentry structs as much as possible... they aren't really necessary for most of this, and are very heavyweight. > If that isn't right, add a CLONE_HANDLES flag for clone() and > add a fd-like table hanging off the task struct. Go all the way, > rather than leaving these features as second-class citizens. I have thought of separating the code in to separate lumps: (1) An in-kernel resident lump, providing very basic services: * handle/handle-map management * object management * some object types * process death-knell notification * file-change notification * unicode string handling/conversion (steal/share from NTFS) * simple RPC mechanism for building certain services in userspace * Win32 syscall stub * int 0x2e stub * /proc view (2) A partial basic Win32 implementation (modulable): * basic Win32 syscalls, eg: CreateMutexA/W * _no_ GDI calls (3) A partial basic Native API implementation (modulable): * basic NT syscalls * again, no GDI calls (4) A userspace registry service, communicating with registry stubs in the kernel by the simple RPC mechanism. > I'd rather not have kernel code that is _only_ good for Win32. > I don't see much reason to have a nasty add-on that can't be > used by regular Linux programs. Agreed. The question is, how much will Linux go for? David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
In article [EMAIL PROTECTED] you wrote: (1) An in-kernel resident lump, providing very basic services: * file-change notification this is interesting for other stuff too, i think irix has an interface for that, i think its an ioctl? * unicode string handling/conversion (steal/share from NTFS) are you sure this needs to be done in the kernel? if you wat to steal the sourcecode of the ntfs driver do it, but why would u wat to share object code for that? * simple RPC mechanism for building certain services in userspace what is that? message passing? in kernel space? (2) A partial basic Win32 implementation (modulable): * basic Win32 syscalls, eg: CreateMutexA/W * _no_ GDI calls actuelly kCGI is there? Greetings Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
At the moment, the Win32 syscalls I implement require an fd to be attached to a particular proc file. This fd holds the Win32 handle map. Huh? Each process needs a handle map... To avoid playing with the task structure, fork, exec, exit, signals, etc., I used an fd attached to a proc file to keep track of the handle map (it gives me reference counting, module tracking, and auto-cleanup on process death). The handle map page is just attached to the private data pointer on the struct file. It was just convenient for starting the whole thing off. There are other ways to make sure the module doesn't go away, for instance using personalities, but I still need to maintain the refcount on the handle map fd. Please don't mess with personalities. I intend to use any useful Win32 or NT-native features in Linux software. Personalities would make these calls only useful for Wine. Agreed. If a Win32 handle can be though of as a file descripter, then just do that. You can invent new file types and new filesystems as needed. These are available: 0x3000 003 0x5000 005 0x7000 007 0x9000 011 0xb000 013 I was trying to avoid using file/inode/dentry structs as much as possible... they aren't really necessary for most of this, and are very heavyweight. If that isn't right, add a CLONE_HANDLES flag for clone() and add a fd-like table hanging off the task struct. Go all the way, rather than leaving these features as second-class citizens. I have thought of separating the code in to separate lumps: (1) An in-kernel resident lump, providing very basic services: * handle/handle-map management * object management * some object types * process death-knell notification * file-change notification * unicode string handling/conversion (steal/share from NTFS) * simple RPC mechanism for building certain services in userspace * Win32 syscall stub * int 0x2e stub * /proc view (2) A partial basic Win32 implementation (modulable): * basic Win32 syscalls, eg: CreateMutexA/W * _no_ GDI calls (3) A partial basic Native API implementation (modulable): * basic NT syscalls * again, no GDI calls (4) A userspace registry service, communicating with registry stubs in the kernel by the simple RPC mechanism. I'd rather not have kernel code that is _only_ good for Win32. I don't see much reason to have a nasty add-on that can't be used by regular Linux programs. Agreed. The question is, how much will Linux go for? David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Hi! > David Howells <[EMAIL PROTECTED]> wrote: > > > >Oliver Neukum <[EMAIL PROTECTED]> wrote: > >> > (3) Even if it was... just filling in the syscall slot from a module means > >> > that it is possible for the module to be unloaded whilst the syscall is in > >> > use. > > Note that all this is not the problem. > > The problem is that dynamic system calls are not going to happen. > > Why? > > License issues. I will not allow system calls to be added from modules. > Because I do not think that adding a system call is a valid thing for a > module to do. It's that easy. > > It's the old thing about "hooks". You must not sidestep the GPL by just > putting a hook in place. And dynamic system calls are the ultimate > hook. Well, you can't stop _GPL-ed_ modules from adding dynamic system calls. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Hi! David Howells [EMAIL PROTECTED] wrote: Oliver Neukum [EMAIL PROTECTED] wrote: (3) Even if it was... just filling in the syscall slot from a module means that it is possible for the module to be unloaded whilst the syscall is in use. Note that all this is not the problem. The problem is that dynamic system calls are not going to happen. Why? License issues. I will not allow system calls to be added from modules. Because I do not think that adding a system call is a valid thing for a module to do. It's that easy. It's the old thing about "hooks". You must not sidestep the GPL by just putting a hook in place. And dynamic system calls are the ultimate hook. Well, you can't stop _GPL-ed_ modules from adding dynamic system calls. Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
In article <[EMAIL PROTECTED]>, David Howells <[EMAIL PROTECTED]> wrote: > >Oliver Neukum <[EMAIL PROTECTED]> wrote: >> > (3) Even if it was... just filling in the syscall slot from a module means >> > that it is possible for the module to be unloaded whilst the syscall is in >> > use. Note that all this is not the problem. The problem is that dynamic system calls are not going to happen. Why? License issues. I will not allow system calls to be added from modules. Because I do not think that adding a system call is a valid thing for a module to do. It's that easy. It's the old thing about "hooks". You must not sidestep the GPL by just putting a hook in place. And dynamic system calls are the ultimate hook. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
At the moment, the Win32 syscalls I implement require an fd to be attached to a particular proc file. This fd holds the Win32 handle map. The VFS provides auto-refcounting on modules that provide file operations, thus the syscall stub only needs to check that the fd provided has the correct set of file operations attached and increment the refcount on the fd itself. This has the added advantage that not only will the module not go away during a syscall, but the handle map will not depart either. There are other ways to make sure the module doesn't go away, for instance using personalities, but I still need to maintain the refcount on the handle map fd. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
At the moment, the Win32 syscalls I implement require an fd to be attached to a particular proc file. This fd holds the Win32 handle map. The VFS provides auto-refcounting on modules that provide file operations, thus the syscall stub only needs to check that the fd provided has the correct set of file operations attached and increment the refcount on the fd itself. This has the added advantage that not only will the module not go away during a syscall, but the handle map will not depart either. There are other ways to make sure the module doesn't go away, for instance using personalities, but I still need to maintain the refcount on the handle map fd. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Tue, 12 Sep 2000, David Woodhouse wrote: > [snip] > > Code your win32 support module to register the PER_WIN32 personality, and > set the sys_win32_handler pointer appropriately. Probably not in that order. > > Could this be a solution for modules that intercept system calls from "normal" processes ? Assuming fork() and friends are intercepted, could a new personality be set which would use-count the module, preventing the unload-whilst-processes-sleeping problem ? I'm unsure whether this lcall7 thing would work at all... would the normal process still go through ENTRY(system_call) ? this would be a much nicer solution than use-counting each system call individually, implying atomic_inc/atomic_dec each time, or making the module unloadable and providing ioctl()s instead of module parameters. Is this possible ? thanks john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
"Albert D. Cahalan" <[EMAIL PROTECTED]> wrote: > You don't need to make this code a module. If somebody else > really wants a module, let them give you a patch. I really want a module... At least while I'm writing the code. I don't want to have to reboot every time I make a change. > The actual Win32/NT code is more important than minor details > about how it is loaded. Being totally in-kernel is easy to do, > easy to use, and better for performance anyway. Some of the code > might even be really useful for non-Win32 software, so it would > be nice to let Linux apps rely on the calls being available. It doesn't make all that much difference in call latency to be in a module rather than in the kernel. Plus you can load it when you need it, and so it's not permanently eating a chunk of non-swappable memory. Additionally, I'm not sure that Linus would put it in the kernel. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Tue, 12 Sep 2000, David Woodhouse wrote: [snip] Code your win32 support module to register the PER_WIN32 personality, and set the sys_win32_handler pointer appropriately. Probably not in that order. Could this be a solution for modules that intercept system calls from "normal" processes ? Assuming fork() and friends are intercepted, could a new personality be set which would use-count the module, preventing the unload-whilst-processes-sleeping problem ? I'm unsure whether this lcall7 thing would work at all... would the normal process still go through ENTRY(system_call) ? this would be a much nicer solution than use-counting each system call individually, implying atomic_inc/atomic_dec each time, or making the module unloadable and providing ioctl()s instead of module parameters. Is this possible ? thanks john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Woodhouse <[EMAIL PROTECTED]> wrote: > Aha. It's a device node provided by the same module? But what happens when > the syscall is invoked with a fd which _isn't_ correct? Well, a /proc file actually... but as part of registering the syscall handler, you also pass a pointer to the file_operations struct, which the stub checks against before calling the handler. David howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
[EMAIL PROTECTED] said:
> I didn't know how to get hold of a "struct pt_regs*" till someone sent
> me a message this morning
Ah. I didn't realise you wanted the struct pt_regs for any purpose other
than to pass to the lcall7 handler - and I was no longer using the lcall7
handler in the sys_win32 stub I posted to you and linux-kernel yesterday
afternoon.
> int (*sys_win32_handler)(args...);
> EXPORT_SYMBOL(sys_win32_handler);
>
> int sys_win32(args...)
> {
> ret = -ENOSYS;
>
> if (current->personality != PER_WIN32) {
> if (sys_personality(PER_WIN32))
> return -ENOSYS;
> }
> /* Now the process has the WIN32 personality, so until it
> exits, we know the module cannot be unloaded.
>*/
>
> return (*sys_win32_handler)(args...);
> }
>
> Code your win32 support module to register the PER_WIN32 personality, and
> set the sys_win32_handler pointer appropriately.
[EMAIL PROTECTED] said:
> Because "getting" the struct file from the fd increments the usage
> count on the struct file. The VFS automatically maintains the module
> count pointed to by the file_operations structure based on the
> existence of the struct file.
Aha. It's a device node provided by the same module? But what happens when
the syscall is invoked with a fd which _isn't_ correct?
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Woodhouse <[EMAIL PROTECTED]> wrote: > The code I posted yesterday is a bit of an abuse of the personality > mechanism, but ought to work nonetheless. Didn't you like it? I didn't know how to get hold of a "struct pt_regs*" till someone sent me a message this morning (it was obvious really). Plus, it occurred to me that I already have this fd I can use for reference counting. > [EMAIL PROTECTED] said: > > thus retaining the existence of the struct file, which then retains > > the module in memory. > > er.. why does it keep the module in memory? Because "getting" the struct file from the fd increments the usage count on the struct file. The VFS automatically maintains the module count pointed to by the file_operations structure based on the existence of the struct file. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Well, I implemented the syscall last night... I decided it was too hard to do a generic syscall handler without writing lots of non-portable assembly to do one of the following (to deal with module reference counting): (1) have a function that concocts a syscall 'thunk' - needs to either transfer the syscall parameters or fiddle the return address and jump to the handler - the latter is hard as the syscall can be called from more than one place in entry.S (2) modify the syscall table layout and the syscall entry code - this is obviously a major piece of work and would affect all architectures. Unpleasant either way. I think (1) would probably be the easiest and certainly the least impact... it just requires providing different thunk writing code on each arch. Anyway, for the moment, I decided on a simple dedicated stub in the kernel proper... This allows me to do reference counting by way of doing a get on the fd that points to the handle map, thus retaining the existence of the struct file, which then retains the module in memory. It all seemed to work, then I removed the printk's, ran a quick check and guess what... it oopsed! Typical. So I'll have to let you have the code this evening or tomorrow when I've squashed the bug. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Woodhouse [EMAIL PROTECTED] wrote: The code I posted yesterday is a bit of an abuse of the personality mechanism, but ought to work nonetheless. Didn't you like it? I didn't know how to get hold of a "struct pt_regs*" till someone sent me a message this morning (it was obvious really). Plus, it occurred to me that I already have this fd I can use for reference counting. [EMAIL PROTECTED] said: thus retaining the existence of the struct file, which then retains the module in memory. er.. why does it keep the module in memory? Because "getting" the struct file from the fd increments the usage count on the struct file. The VFS automatically maintains the module count pointed to by the file_operations structure based on the existence of the struct file. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
[EMAIL PROTECTED] said:
I didn't know how to get hold of a "struct pt_regs*" till someone sent
me a message this morning
Ah. I didn't realise you wanted the struct pt_regs for any purpose other
than to pass to the lcall7 handler - and I was no longer using the lcall7
handler in the sys_win32 stub I posted to you and linux-kernel yesterday
afternoon.
int (*sys_win32_handler)(args...);
EXPORT_SYMBOL(sys_win32_handler);
int sys_win32(args...)
{
ret = -ENOSYS;
if (current-personality != PER_WIN32) {
if (sys_personality(PER_WIN32))
return -ENOSYS;
}
/* Now the process has the WIN32 personality, so until it
exits, we know the module cannot be unloaded.
*/
return (*sys_win32_handler)(args...);
}
Code your win32 support module to register the PER_WIN32 personality, and
set the sys_win32_handler pointer appropriately.
[EMAIL PROTECTED] said:
Because "getting" the struct file from the fd increments the usage
count on the struct file. The VFS automatically maintains the module
count pointed to by the file_operations structure based on the
existence of the struct file.
Aha. It's a device node provided by the same module? But what happens when
the syscall is invoked with a fd which _isn't_ correct?
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
> David Howells <[EMAIL PROTECTED]> wrote:
> > Now there's an idea... have the kernel autoload modules based on a
> > particular syscall number being handled in that module. Madness
> > *grin*.
[EMAIL PROTECTED] said:
> No more madness than kmod loading a module called char-major-10-135
> for /dev/rtc. Or code that uses modules.pcimap to work out which
> module to load for a PCI device. Just teach kmod to load
> syscall-agent-86 if you want to get smart.
... and make it handle the use count on the module properly.
struct syscall {
struct module *owner;
int (*handler)();
int whatever_other_random_thing_MIPS_keeps_in_syscall_table;
} syscall_table[__NR_syscalls]
Yeuch.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Tue, 12 Sep 2000 14:54:29 +0100, David Howells <[EMAIL PROTECTED]> wrote: >Oliver Neukum <[EMAIL PROTECTED]> wrote: >> This seems to me the best idea. However I would argue against dynamically >> allocating syscalls. Reserving numbers makes for better code and allows you >> to do autoloading. > >Now there's an idea... have the kernel autoload modules based on a particular >syscall number being handled in that module. Madness *grin*. No more madness than kmod loading a module called char-major-10-135 for /dev/rtc. Or code that uses modules.pcimap to work out which module to load for a PCI device. Just teach kmod to load syscall-agent-86 if you want to get smart. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
[EMAIL PROTECTED] said:
> But where do I get the other argument (struct pt_regs *) from? A
> normal Linux syscall does not appear to have access to such a beast...
With difficulty. A normal syscall wouldn't generally go through the lcall7
handler. Some of the ABI/iBCS code gets access to the struct pt_regs
though. It's probably not the best way to go, though.
Try something along these lines...
int (*sys_win32_handler)(args...);
EXPORT_SYMBOL(sys_win32_handler);
int sys_win32(args...)
{
ret = -ENOSYS;
if (current->personality != PER_WIN32) {
if (sys_personality(PER_WIN32))
return -ENOSYS;
}
/* Now the process has the WIN32 personality, so until it
exits, we know the module cannot be unloaded.
*/
return (*sys_win32_handler)(args...);
}
Code your win32 support module to register the PER_WIN32 personality, and
set the sys_win32_handler pointer appropriately. Probably not in that order.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Oliver Neukum <[EMAIL PROTECTED]> wrote: > > I think now that I'm probably best providing a generic pluggable syscall > > handler, one that is very careful to make sure the syscall can't be entered > > whilst the module is being unloaded. > > This seems to me the best idea. However I would argue against dynamically > allocating syscalls. Reserving numbers makes for better code and allows you > to do autoloading. Now there's an idea... have the kernel autoload modules based on a particular syscall number being handled in that module. Madness *grin*. You still have to have a static syscall number though... David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Woodhouse <[EMAIL PROTECTED]> wrote: > You don't need to add another handler. I already overloaded the lcall7 > handler by passing an extra int into it to tell it the type of call which is > causing it to be invoked. Values which are already used are 7 for iBCS calls > (lcall7) and 0x27 for Solaris/x86 syscalls (lcall 0x27). Pick another > number, and possibly reassign those two to 1 and 2 respectively because it's > cleaner like that. But where do I get the other argument (struct pt_regs *) from? A normal Linux syscall does not appear to have access to such a beast... David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
[EMAIL PROTECTED] said: > Ah... I did misunderstand you. I thought you meant CONFIG_MODULES in > general, which'd be okay - obviously, if module support is disabled, > you can't load a module anyway. Well actually, that's not strictly true. But it is fair to say that if you're hacking new code into the kernel with CONFIG_MODULES disabled, then we really don't care about you :) [EMAIL PROTECTED] said: > No, I wasn't planning to do that. I was thinking more along the lines > of adding another handler in to struct exec_domain, but that isn't > especially generic. You don't need to add another handler. I already overloaded the lcall7 handler by passing an extra int into it to tell it the type of call which is causing it to be invoked. Values which are already used are 7 for iBCS calls (lcall7) and 0x27 for Solaris/x86 syscalls (lcall 0x27). Pick another number, and possibly reassign those two to 1 and 2 respectively because it's cleaner like that. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Richard Guenther <[EMAIL PROTECTED]> wrote: > Whats the problem with just not allowing the module to unload at all? > Whats the point in unloading a module anyways. Ok, I know - debugging, > etc. - but for a "release" version this is not important. Also upgrading - > but for desktop boxes (for which this wine stuff is) rebooting seems > appropriate here, too. It's not all that hard to do... and it does mean you can have demand-loadable and -unloadable modules. Also I am writing/debugging it at the moment, and so I like being able to unload and reload the module. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Tue, 12 Sep 2000, David Howells wrote: > > I think now that I'm probably best providing a generic pluggable syscall > handler, one that is very careful to make sure the syscall can't be entered > whilst the module is being unloaded. > Whats the problem with just not allowing the module to unload at all? Whats the point in unloading a module anyways. Ok, I know - debugging, etc. - but for a "release" version this is not important. Also upgrading - but for desktop boxes (for which this wine stuff is) rebooting seems appropriate here, too. Richard. -- Richard Guenther <[EMAIL PROTECTED]> WWW: http://www.anatom.uni-tuebingen.de/~richi/ The GLAME Project: http://www.glame.de/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Woodhouse <[EMAIL PROTECTED]> wrote: > Unless it's _absolutely_ necessary, the kernel image (i.e. vmlinux) should > not contain any code which is dependent on CONFIG_*_MODULE options. > > Therefore, stuff like... > > #ifdef CONFIG_WIN32_MODULE > EXPORT_SYMBOL(my_win32_helper_func); > #endif > > ...would mean that you have to recompile the kernel and reboot to enable the > module, rather than just compiling and loading the module. Ah... I did misunderstand you. I thought you meant CONFIG_MODULES in general, which'd be okay - obviously, if module support is disabled, you can't load a module anyway. No, I wasn't planning to do that. I was thinking more along the lines of adding another handler in to struct exec_domain, but that isn't especially generic. I think now that I'm probably best providing a generic pluggable syscall handler, one that is very careful to make sure the syscall can't be entered whilst the module is being unloaded. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Tue, 12 Sep 2000 12:40:45 +0200 (CEST),
[EMAIL PROTECTED] (Arjan van de Ven) wrote:
>In article <[EMAIL PROTECTED]> you wrote:
>> #ifdef CONFIG_MODULES
>> EXPORT_SYMBOL(dynamic_syscall_in_modules_helper);
>> #endif
>
>I think this is total bullshit. EXPORT_SYMBOLS should be a nop anyway if
>modules are turned off, as there is no use for it.
Absolutely correct. I was being a bit short with that example, in real
life it would be more like this.
#ifdef CONFIG_MODULES
int dynamic_syscall_in_modules_helper(int syscall, struct module *mod)
{
/* blah, blah, blah */
}
EXPORT_SYMBOL(dynamic_syscall_in_modules_helper);
#endif
The whole function would depend on CONFIG_MODULES, not just the export.
That's what I get for trying to save bandwidth ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
In article <[EMAIL PROTECTED]> you wrote: > #ifdef CONFIG_MODULES > EXPORT_SYMBOL(dynamic_syscall_in_modules_helper); > #endif I think this is total bullshit. EXPORT_SYMBOLS should be a nop anyway if modules are turned off, as there is no use for it. Greetings, Arjan van de Ven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Tue, 12 Sep 2000 10:25:16 +0100, David Woodhouse <[EMAIL PROTECTED]> wrote: >Unless it's _absolutely_ necessary, the kernel image (i.e. vmlinux) should >not contain any code which is dependent on CONFIG_*_MODULE options. > >Therefore, stuff like... > >#ifdef CONFIG_WIN32_MODULE > EXPORT_SYMBOL(my_win32_helper_func); >#endif > >...would mean that you have to recompile the kernel and reboot to enable the >module, rather than just compiling and loading the module. But this is quite valid ... #ifdef CONFIG_MODULES EXPORT_SYMBOL(dynamic_syscall_in_modules_helper); #endif Use a generic helper for dynamic syscalls in modules, not tied to any particular module or config option. You have to use a different kernel if you turn the top level CONFIG_MODULES on. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
[EMAIL PROTECTED] said: > I have to admit, the thought hadn't occurred to me to do that. It > almost sounds like a good idea... after all the stub can't be used if > no modules can be loaded. Are you thinking, then, that the stub can't > be used by compiled in (ie non-module) code? Or am I misunderstanding > what you mean? Unless it's _absolutely_ necessary, the kernel image (i.e. vmlinux) should not contain any code which is dependent on CONFIG_*_MODULE options. Therefore, stuff like... #ifdef CONFIG_WIN32_MODULE EXPORT_SYMBOL(my_win32_helper_func); #endif ...would mean that you have to recompile the kernel and reboot to enable the module, rather than just compiling and loading the module. For something which is likely to be distributed separately from the kernel, this would be particularly painful. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Woodhouse <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] said: > > The best solution is to have a stub which is always resident that > > does the inc/dec of the module count. This stub can reserve the > > syscall number as well. > > _Please_ don't have a stub in the kernel which is conditionally compiled > according to the value of a _MODULE option. I have to admit, the thought hadn't occurred to me to do that. It almost sounds like a good idea... after all the stub can't be used if no modules can be loaded. Are you thinking, then, that the stub can't be used by compiled in (ie non-module) code? Or am I misunderstanding what you mean? David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Woodhouse [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] said: The best solution is to have a stub which is always resident that does the inc/dec of the module count. This stub can reserve the syscall number as well. _Please_ don't have a stub in the kernel which is conditionally compiled according to the value of a _MODULE option. I have to admit, the thought hadn't occurred to me to do that. It almost sounds like a good idea... after all the stub can't be used if no modules can be loaded. Are you thinking, then, that the stub can't be used by compiled in (ie non-module) code? Or am I misunderstanding what you mean? David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
[EMAIL PROTECTED] said: I have to admit, the thought hadn't occurred to me to do that. It almost sounds like a good idea... after all the stub can't be used if no modules can be loaded. Are you thinking, then, that the stub can't be used by compiled in (ie non-module) code? Or am I misunderstanding what you mean? Unless it's _absolutely_ necessary, the kernel image (i.e. vmlinux) should not contain any code which is dependent on CONFIG_*_MODULE options. Therefore, stuff like... #ifdef CONFIG_WIN32_MODULE EXPORT_SYMBOL(my_win32_helper_func); #endif ...would mean that you have to recompile the kernel and reboot to enable the module, rather than just compiling and loading the module. For something which is likely to be distributed separately from the kernel, this would be particularly painful. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Tue, 12 Sep 2000 10:25:16 +0100, David Woodhouse [EMAIL PROTECTED] wrote: Unless it's _absolutely_ necessary, the kernel image (i.e. vmlinux) should not contain any code which is dependent on CONFIG_*_MODULE options. Therefore, stuff like... #ifdef CONFIG_WIN32_MODULE EXPORT_SYMBOL(my_win32_helper_func); #endif ...would mean that you have to recompile the kernel and reboot to enable the module, rather than just compiling and loading the module. But this is quite valid ... #ifdef CONFIG_MODULES EXPORT_SYMBOL(dynamic_syscall_in_modules_helper); #endif Use a generic helper for dynamic syscalls in modules, not tied to any particular module or config option. You have to use a different kernel if you turn the top level CONFIG_MODULES on. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
In article [EMAIL PROTECTED] you wrote: #ifdef CONFIG_MODULES EXPORT_SYMBOL(dynamic_syscall_in_modules_helper); #endif I think this is total bullshit. EXPORT_SYMBOLS should be a nop anyway if modules are turned off, as there is no use for it. Greetings, Arjan van de Ven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Tue, 12 Sep 2000 12:40:45 +0200 (CEST),
[EMAIL PROTECTED] (Arjan van de Ven) wrote:
In article [EMAIL PROTECTED] you wrote:
#ifdef CONFIG_MODULES
EXPORT_SYMBOL(dynamic_syscall_in_modules_helper);
#endif
I think this is total bullshit. EXPORT_SYMBOLS should be a nop anyway if
modules are turned off, as there is no use for it.
Absolutely correct. I was being a bit short with that example, in real
life it would be more like this.
#ifdef CONFIG_MODULES
int dynamic_syscall_in_modules_helper(int syscall, struct module *mod)
{
/* blah, blah, blah */
}
EXPORT_SYMBOL(dynamic_syscall_in_modules_helper);
#endif
The whole function would depend on CONFIG_MODULES, not just the export.
That's what I get for trying to save bandwidth ...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Woodhouse [EMAIL PROTECTED] wrote: Unless it's _absolutely_ necessary, the kernel image (i.e. vmlinux) should not contain any code which is dependent on CONFIG_*_MODULE options. Therefore, stuff like... #ifdef CONFIG_WIN32_MODULE EXPORT_SYMBOL(my_win32_helper_func); #endif ...would mean that you have to recompile the kernel and reboot to enable the module, rather than just compiling and loading the module. Ah... I did misunderstand you. I thought you meant CONFIG_MODULES in general, which'd be okay - obviously, if module support is disabled, you can't load a module anyway. No, I wasn't planning to do that. I was thinking more along the lines of adding another handler in to struct exec_domain, but that isn't especially generic. I think now that I'm probably best providing a generic pluggable syscall handler, one that is very careful to make sure the syscall can't be entered whilst the module is being unloaded. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Tue, 12 Sep 2000, David Howells wrote: I think now that I'm probably best providing a generic pluggable syscall handler, one that is very careful to make sure the syscall can't be entered whilst the module is being unloaded. Whats the problem with just not allowing the module to unload at all? Whats the point in unloading a module anyways. Ok, I know - debugging, etc. - but for a "release" version this is not important. Also upgrading - but for desktop boxes (for which this wine stuff is) rebooting seems appropriate here, too. Richard. -- Richard Guenther [EMAIL PROTECTED] WWW: http://www.anatom.uni-tuebingen.de/~richi/ The GLAME Project: http://www.glame.de/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Richard Guenther [EMAIL PROTECTED] wrote: Whats the problem with just not allowing the module to unload at all? Whats the point in unloading a module anyways. Ok, I know - debugging, etc. - but for a "release" version this is not important. Also upgrading - but for desktop boxes (for which this wine stuff is) rebooting seems appropriate here, too. It's not all that hard to do... and it does mean you can have demand-loadable and -unloadable modules. Also I am writing/debugging it at the moment, and so I like being able to unload and reload the module. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
[EMAIL PROTECTED] said: Ah... I did misunderstand you. I thought you meant CONFIG_MODULES in general, which'd be okay - obviously, if module support is disabled, you can't load a module anyway. Well actually, that's not strictly true. But it is fair to say that if you're hacking new code into the kernel with CONFIG_MODULES disabled, then we really don't care about you :) [EMAIL PROTECTED] said: No, I wasn't planning to do that. I was thinking more along the lines of adding another handler in to struct exec_domain, but that isn't especially generic. You don't need to add another handler. I already overloaded the lcall7 handler by passing an extra int into it to tell it the type of call which is causing it to be invoked. Values which are already used are 7 for iBCS calls (lcall7) and 0x27 for Solaris/x86 syscalls (lcall 0x27). Pick another number, and possibly reassign those two to 1 and 2 respectively because it's cleaner like that. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Woodhouse [EMAIL PROTECTED] wrote: You don't need to add another handler. I already overloaded the lcall7 handler by passing an extra int into it to tell it the type of call which is causing it to be invoked. Values which are already used are 7 for iBCS calls (lcall7) and 0x27 for Solaris/x86 syscalls (lcall 0x27). Pick another number, and possibly reassign those two to 1 and 2 respectively because it's cleaner like that. But where do I get the other argument (struct pt_regs *) from? A normal Linux syscall does not appear to have access to such a beast... David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Oliver Neukum [EMAIL PROTECTED] wrote: I think now that I'm probably best providing a generic pluggable syscall handler, one that is very careful to make sure the syscall can't be entered whilst the module is being unloaded. This seems to me the best idea. However I would argue against dynamically allocating syscalls. Reserving numbers makes for better code and allows you to do autoloading. Now there's an idea... have the kernel autoload modules based on a particular syscall number being handled in that module. Madness *grin*. You still have to have a static syscall number though... David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
[EMAIL PROTECTED] said:
But where do I get the other argument (struct pt_regs *) from? A
normal Linux syscall does not appear to have access to such a beast...
With difficulty. A normal syscall wouldn't generally go through the lcall7
handler. Some of the ABI/iBCS code gets access to the struct pt_regs
though. It's probably not the best way to go, though.
Try something along these lines...
int (*sys_win32_handler)(args...);
EXPORT_SYMBOL(sys_win32_handler);
int sys_win32(args...)
{
ret = -ENOSYS;
if (current-personality != PER_WIN32) {
if (sys_personality(PER_WIN32))
return -ENOSYS;
}
/* Now the process has the WIN32 personality, so until it
exits, we know the module cannot be unloaded.
*/
return (*sys_win32_handler)(args...);
}
Code your win32 support module to register the PER_WIN32 personality, and
set the sys_win32_handler pointer appropriately. Probably not in that order.
--
dwmw2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Tue, 12 Sep 2000 14:54:29 +0100, David Howells [EMAIL PROTECTED] wrote: Oliver Neukum [EMAIL PROTECTED] wrote: This seems to me the best idea. However I would argue against dynamically allocating syscalls. Reserving numbers makes for better code and allows you to do autoloading. Now there's an idea... have the kernel autoload modules based on a particular syscall number being handled in that module. Madness *grin*. No more madness than kmod loading a module called char-major-10-135 for /dev/rtc. Or code that uses modules.pcimap to work out which module to load for a PCI device. Just teach kmod to load syscall-agent-86 if you want to get smart. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Howells wrote: > > Oliver Neukum <[EMAIL PROTECTED]> wrote: > > I see two possible solutions. > > > > Either you make that function available to user space by your syscall. > > Not a good idea... the whole point is to make sure no one is in a syscall when > the module is unloaded. If you do it this way, the tail end of this syscall > can fight with the module unload code. > > > Or you find a way to hook into task termination. > > I'm already doing that... See the release() call on the fd. But this doesn't > stop someone from invoking a syscall at an inappropriate time. > > David Howells > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ The best solution is to have a stub which is always resident that does the inc/dec of the module count. This stub can reserve the syscall number as well. -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
"Albert D. Cahalan" <[EMAIL PROTECTED]> wrote: > The system call is needed of course, since that lets Linux executables > (perhaps ones being ported from Win32) use the new features. It also means that non-i386 and non-wine use these services if they want to. > You might as well also handle int 0x2e with the same code. I suppose... provide three modules maybe: (1) the object and handle support mechanism; (2) the Win32 API (what of it I decide to implement in a kernel module) and syscall; and (3) the Native API and interrupt. > See www.sysinternals.com for some native API documentation. > In addition to the web site, there are articles and a book. Been there... he says that you can't get all the API documentation. > The native API is generally better for Linux, because it is smaller > and less bloated than Win32. Agreed. > Putting Win32 in the kernel is almost like putting libc in the kernel. You > can make exceptions for calls that need the greatest performance and/or > don't translate well. Also agreed, particularly when GDI calls are considered. Though this also applies to the Native API. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Howells writes: > David Woodhouse <[EMAIL PROTECTED]> wrote: >> We already handle doing iBCS and Solaris syscalls by trapping int 7 and >> int 0x27 insns and using a dedicated syscall handler - it doesn't go >> anywhere near the original Linux syscall table. > > I was planning on having using a Linux syscall rather than an > interrupt, since the int ties it to i386. The system call is needed of course, since that lets Linux executables (perhaps ones being ported from Win32) use the new features. You might as well also handle int 0x2e with the same code. >> What method does Win32 use to execute syscalls? Would it be >> useful to trap that directly? > > It does and it doesn't is the answer I think. NT/Win2000 certainly > does not... kernel32.dll renders the Win32 calls into "Native API" > calls, which are defined in ntdll.dll. These use "int 0x2e" to obtain > access to the kernel, but are mostly undocumented (typically). See www.sysinternals.com for some native API documentation. In addition to the web site, there are articles and a book. The native API is generally better for Linux, because it is smaller and less bloated than Win32. Putting Win32 in the kernel is almost like putting libc in the kernel. You can make exceptions for calls that need the greatest performance and/or don't translate well. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Oliver Neukum <[EMAIL PROTECTED]> wrote: > > How does handle_unload_preparation() get invoked? And does lock_kernel() > > Explicitly, or via proc or sysctl. Alright, let me ask that a different way: If I provide such a function in the module, _what_ calls it from the main kernel? David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Oliver Neukum <[EMAIL PROTECTED]> wrote:
> > (3) Even if it was... just filling in the syscall slot from a module means
> > that it is possible for the module to be unloaded whilst the syscall is in
> > use.
> >
> > David Howells
>
> The following scheme might work:
>
> On module load: INC_MOD_USE_COUNT
>
> In the module
>
> int handle_unload_preparation()
> {
> if (!suser())
> return -EPERM;
>
> lock_kernel();
> *call_table_entry = dummy_function;
> wmb();
> unlock_kernel();
>
> return 0;
> }
>
> Regards
> Oliver
How does handle_unload_preparation() get invoked? And does lock_kernel()
suppress syscall access?
David Howells
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Oliver Neukum <[EMAIL PROTECTED]> wrote: > So ask Linus for one. The streams group got one. Why shouldn't yo ? Well, that's up to Linus... but from his email on this subject, he might well. > Having a static syscall should be more efficient, too. A little... otherwise it's a matter once per process of reading a line from the /proc file, pulling out the number (or reading via an ioctl) and keeping it in a global variable, rather than having it as immediate data on an assembly instruction. > It need not be. True... but it isn't at the moment. > You should be able to steal a solution from knfsd. It faces the same problem. > Of course it takes a small stub that's always in kernel, but so what. Interesting idea... I'll take a look. Maybe it'll be possible to share something. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Oliver Neukum <[EMAIL PROTECTED]> wrote: > What is the difference to get one reserved syscall and multiplex it ? This is what I'd like to be able to do... that way the checks that ioctl() performs can be avoided. However, there are problems with doing this: (1) There's currently no definitive way to grab an unused syscall, whether a random one or a pre-determined one. (2) The syscall table is not exported... (3) Even if it was... just filling in the syscall slot from a module means that it is possible for the module to be unloaded whilst the syscall is in use. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Dan Maas <[EMAIL PROTECTED]> wrote: > This is done all the time -- with ioctl(). It's perfectly normal to create a > special character device that just responds to an ioctl for each operation > you want to perform. See eg any sound card driver... Yes, that's how I'm doing it at the moment. However, this incurs a penalty because of the the number of standard ioctl()'s the system checks for first, before passing the command to my handler. What Robert suggested was to use write() to do the deed, which I don't think is a good idea. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
"J. Robert von Behren" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Dan Maas [EMAIL PROTECTED] wrote: This is done all the time -- with ioctl(). It's perfectly normal to create a special character device that just responds to an ioctl for each operation you want to perform. See eg any sound card driver... Yes, that's how I'm doing it at the moment. However, this incurs a penalty because of the the number of standard ioctl()'s the system checks for first, before passing the command to my handler. What Robert suggested was to use write() to do the deed, which I don't think is a good idea. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Oliver Neukum [EMAIL PROTECTED] wrote: What is the difference to get one reserved syscall and multiplex it ? This is what I'd like to be able to do... that way the checks that ioctl() performs can be avoided. However, there are problems with doing this: (1) There's currently no definitive way to grab an unused syscall, whether a random one or a pre-determined one. (2) The syscall table is not exported... (3) Even if it was... just filling in the syscall slot from a module means that it is possible for the module to be unloaded whilst the syscall is in use. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Oliver Neukum [EMAIL PROTECTED] wrote: So ask Linus for one. The streams group got one. Why shouldn't yo ? Well, that's up to Linus... but from his email on this subject, he might well. Having a static syscall should be more efficient, too. A little... otherwise it's a matter once per process of reading a line from the /proc file, pulling out the number (or reading via an ioctl) and keeping it in a global variable, rather than having it as immediate data on an assembly instruction. It need not be. True... but it isn't at the moment. You should be able to steal a solution from knfsd. It faces the same problem. Of course it takes a small stub that's always in kernel, but so what. Interesting idea... I'll take a look. Maybe it'll be possible to share something. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Howells writes: David Woodhouse [EMAIL PROTECTED] wrote: We already handle doing iBCS and Solaris syscalls by trapping int 7 and int 0x27 insns and using a dedicated syscall handler - it doesn't go anywhere near the original Linux syscall table. I was planning on having using a Linux syscall rather than an interrupt, since the int ties it to i386. The system call is needed of course, since that lets Linux executables (perhaps ones being ported from Win32) use the new features. You might as well also handle int 0x2e with the same code. What method does Win32 use to execute syscalls? Would it be useful to trap that directly? It does and it doesn't is the answer I think. NT/Win2000 certainly does not... kernel32.dll renders the Win32 calls into "Native API" calls, which are defined in ntdll.dll. These use "int 0x2e" to obtain access to the kernel, but are mostly undocumented (typically). See www.sysinternals.com for some native API documentation. In addition to the web site, there are articles and a book. The native API is generally better for Linux, because it is smaller and less bloated than Win32. Putting Win32 in the kernel is almost like putting libc in the kernel. You can make exceptions for calls that need the greatest performance and/or don't translate well. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
"Albert D. Cahalan" [EMAIL PROTECTED] wrote: The system call is needed of course, since that lets Linux executables (perhaps ones being ported from Win32) use the new features. It also means that non-i386 and non-wine use these services if they want to. You might as well also handle int 0x2e with the same code. I suppose... provide three modules maybe: (1) the object and handle support mechanism; (2) the Win32 API (what of it I decide to implement in a kernel module) and syscall; and (3) the Native API and interrupt. See www.sysinternals.com for some native API documentation. In addition to the web site, there are articles and a book. Been there... he says that you can't get all the API documentation. The native API is generally better for Linux, because it is smaller and less bloated than Win32. Agreed. Putting Win32 in the kernel is almost like putting libc in the kernel. You can make exceptions for calls that need the greatest performance and/or don't translate well. Also agreed, particularly when GDI calls are considered. Though this also applies to the Native API. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
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" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Thu, Sep 07, 2000 at 10:46:58AM +0200, Martin Dalecki wrote: > > I've done an implementation of some of the Win32 "system calls" in a kernel > > module in an attempt to speed up Wine. > > Please by no way don't include this patch into the official tree. > It's insane due to the following: > > 1. Linux is UNIX not NT... (in terms of API) I also don't think this patch should go into the official tree, but in my case it's because it's too closely related to the WINE userspace libraries; it should become part of the WINE tree instead. (Note that this is how other packages such as ALSA and lm_sensors are maintained.) However, I don't see any problems with having a kernel module to emulate a different API. We already have code to emulate different UNIX APIs in the IBCS system; having some support for emulating the Win32 system call interface could potentially be useful. > 2. WINE in itself is barely usefull - even in fact non existant, since > there is no official stable release out there. Flamebait, but I don't think this is true. WINE is very useful---plenty of apps and games run on it, and it can be a real lifesaver if you get thrown a self-extracting archive that unzip chokes on. (Note that Corel are using WINE for Wordperfect Office under Unix now.) WINE's still-ALPHA status reflects the caution of its developers rather than the quality of its code; note that plenty of other packages (lesstif, kbd, WindowMaker, ORBit, ALSA, bin86, esd, links etc.) still retain "alpha" (<1.0) version numbers despite being stable, reliable and widely-used. -- Adam Sampson [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
"J. Robert von Behren" <[EMAIL PROTECTED]> 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? 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. Far better to use ioctl() I think. > Nonetheless, having some entries in the syscall table that are > designated as "dynamically allocatable" would be a nifty trick. If the > kernel managed these, modules coluld safely grab a few at load time, and > then declare which indices to use via a /proc file. My thought exactly, except that you either need one or a great many. David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
David Howells wrote: > (2) Some sort of support for (dynamically allocated) system calls implemented > in modules. 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. Nonetheless, having some entries in the syscall table that are designated as "dynamically allocatable" would be a nifty trick. If the kernel managed these, modules coluld safely grab a few at load time, and then declare which indices to use via a /proc file. -Rob von Behren - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Fri, Sep 08, 2000 at 02:12:09PM +0100, David Howells wrote: > > (1) A death-knell callback list to be placed in the task structure. Each > function so listed (if any) would be invoked upon exit, signal-death or > execve. The SGI accounting project (and other accouting projects which are underway) will need similar hooks, so it is not even only required for Wine. > > (2) Some sort of support for (dynamically allocated) system calls implemented > in modules. Well, that already exists. It is called ioctl. How would the user look up dynamically allocated system calls anyways, assuming multiple modules etc.? Ioctls have that name space probably already neatly solved. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
[EMAIL PROTECTED] said: > We used to have the iBCS2 project, and I was actually considering > making it part of the standard kernel when it started becoming a > non-issue simply because there started to be more native Linux > programs than iBCS2 programs. Actually, you seemed to be considering it quite seriously a few months back. I spent a week cleaning it up at your request, but then I think the mail containing the patch was sent at about the same time as you sent the mail announcing the feature freeze. As I knew the feature freeze was coming, I was quite rushed, so I didn't clean it up as much as perhaps I should have done. There are still good reasons for including it. The PA-RISC people want HPUX emulation, which shares a lot of code with the other *NIX emulations. I was intending to dust it off and spend a little more time cleaning it up properly when you started taking patches for 2.5. I'd actually quite like to see support for older Linux personalities also being shifted into a configurable module along with the other emulations - there's a lot of cruft that you can safely eliminate on an embedded system where you _know_ they're never going to be running libc5 binaries. -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Horst von Brand <[EMAIL PROTECTED]> wrote: > Lost me there. If after releasing the mutex it is free, the release was > sucessful AFAIAC. If two threads try to do it at the same time, so what? > Releasing an already free mutex is broken, OK. But two threads owning the > mutex at the same time is much worse... Because the mutex release is done in two stages: (1) clear the state bit and (2) set the owner pointer to NULL. This is a sufficient window for a potential mutex grabber to jump in grab the mutex and then have stage (2) clobber the owner pointer. Anyway, I've changed this now (though I haven't got around to testing it yet): On platforms that support cmpxchg(), it uses the owner pointer as the state and exchanges it to NULL to release the mutex, and exchanges it to the owner pointer when grabbing. On platforms that don't, a spinlock is added to the WineMutex structure. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
Horst von Brand [EMAIL PROTECTED] wrote: Lost me there. If after releasing the mutex it is free, the release was sucessful AFAIAC. If two threads try to do it at the same time, so what? Releasing an already free mutex is broken, OK. But two threads owning the mutex at the same time is much worse... Because the mutex release is done in two stages: (1) clear the state bit and (2) set the owner pointer to NULL. This is a sufficient window for a potential mutex grabber to jump in grab the mutex and then have stage (2) clobber the owner pointer. Anyway, I've changed this now (though I haven't got around to testing it yet): On platforms that support cmpxchg(), it uses the owner pointer as the state and exchanges it to NULL to release the mutex, and exchanges it to the owner pointer when grabbing. On platforms that don't, a spinlock is added to the WineMutex structure. David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Wine speedup through kernel module
On Fri, Sep 08, 2000 at 02:12:09PM +0100, David Howells wrote: (1) A death-knell callback list to be placed in the task structure. Each function so listed (if any) would be invoked upon exit, signal-death or execve. The SGI accounting project (and other accouting projects which are underway) will need similar hooks, so it is not even only required for Wine. (2) Some sort of support for (dynamically allocated) system calls implemented in modules. Well, that already exists. It is called ioctl. How would the user look up dynamically allocated system calls anyways, assuming multiple modules etc.? Ioctls have that name space probably already neatly solved. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
