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    [W:0.035 / U:2.544 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site