Messages in this thread |  | | Subject | Re: [RFC] Wine speedup through kernel module | Date | Thu, 21 Sep 2000 16:17:48 +0100 | From | David Howells <> |
| |
"Albert D. Cahalan" <acahalan@cs.uml.edu> 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |