> (I have to report, I think, that I rewrote the userspace
> interface, and I
> managed to get something like a 20% better turn around time
> in a tight mutex
> loop than Win2000 executing the same loop *evil grin*).
I think it is because the Linux syscall mechanism is faster.
In any case a totally meaningless benchmark since there is
no practial use in doing a tight mutex loop.
However, it might be useful for marketing Wine. :-)
> However, I don't think that, for instance, the registry is
> particularly
> suitable to Linux kernel space. If it was stored in specially
> allocated slab
> memory caches (making it trivial to dispose of), with all the
> keys as unicode
> and linkage blocks forming a tree structure, it would take
> rather a lot of
> unswappable memory.
The registry is a file system (almost). The main difference
is that the "directories" can have content as well.
It would be nice to be able to mount (loopback mount) the
registry files. This means that
1. The registry can be seen and changed in the Unix file system
with normal Unix applications.
2. We can use the special Wine syscall to manipulate data
according to the Windows API.
> As for building from the same sources, I don't think that's
> practical either,
> since the set of functions available in the two spaces is
> different (though
> you can make system calls from kernel-space, I don't
> recommend it in this
> case).
The fact that "the set of functions available in the two
spaces is different" does not nessary mean that sharing
source is ruled out it depend largely on how many #ifdef
you need to hide the differences. Note that many things
can be hidden in the header files.
> (1) We could use a spare system call to provide access to the
> kernel module,
> rather than using ioctl as I do now. This will bypass the
> overhead of
> ioctl looking for standard, internal commands to deal with first.
Yes, I think should have a special syscall for this.
Somebody earlier mentioned using the mechnism that NT (int 2e IIRC),
the problem with this is that IIRC the syscall numbers are not
constant they are dependent on the version of the NT kernel.
They are IIRC sorted in alphabetic order. This means that the
native NTDLL.DLL will not run under Wine regardless so it
is not much use in doing that.
However, I think, with the exception of the overhead,
that the ioctl interface is good in principle.
Just add a syscall called
int winecall(int id, void *data);
this gives flexibillity. We can add as many new "winecall":s
as we like using this interface.
Note that if you layout the call structure _exactly_ the same
way as the stack layout (which is fixed for all Windows API functions).
You will get an even faster call mechanism that you currently have.
Just load a register with the call id another with the offset:ed
stack pointer and then sys call.
I wonder how many percent faster that will be?
PS. Perhaps you should ask Linus about reserving a syscall for
Wine before 2.4 is released in order to miniminze support
problems.
