lkml.org 
[lkml]   [2000]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] Wine speedup through kernel module
Date
From

"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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [from the cache]
©2003-2011 Jasper Spaans