lkml.org 
[lkml]   [2000]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [RFC] Wine speedup through kernel module
    Date
    David Howells writes:
    > Waldek Hebisch <hebisch@math.uni.wroc.pl> 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--w---- 1 acahalan 0 Sep 21 09:33 720429
    mrw--w---- 1 acahalan 0 Sep 18 19:33 2852
    mrw------- 1 acahalan 0 Sep 21 09:33 53245325
    mrw--w---- 1 acahalan 0 Sep 21 09:33 88234
    $ ls -log /event
    total 0
    erw------- 1 acahalan 0 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 majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:38    [W:0.028 / U:0.972 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site