Patrik Stridvall <[EMAIL PROTECTED]> wrote:
> 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. :-)
True... It is however 900% or better faster than straight wine.
> 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
Are you thinking of mounting Windows registry hives directly? If so, don't
forget: (1) the windows registry spans several hive files, (2) hives can be
added by user processes, (3) what about change notifications, (4) what about
dynamic data, and (5) what about meta-data (type, etc.).
Admittedly, some this might be solved by a filesystem, particularly if you can
mount registry filesystems on registry filesystems (equivalent to adding
hives) and use symbolic links to emulate registry symlinks.
> 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.
Hmmm... You have to emulate all the locking stuff it you want to be able to
multithread your userspace-only server.
Actually, what you can probably do is write the server as a kernel module, and
then emulate the kernel services in userland. I did this to some extent in a
small testbed program that I wrote so I could trace the kernel module easily
with gdb.
> Yes, I think should have a special syscall for this.
> ...
> 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.
We'd have to persuade Linus to part with one. Maybe attaching it to the
exec_domain/personality stuff.
We'd also have to be _very_ careful using it if the wineserver is in a module,
otherwise the module might go away whilst we're using it, but that shouldn't
be a problem.
> I use ioctl because (a) it already exists, (b) I don't have to change the
> kernel to use it, and (c) I'm using a file descriptor to control the lifetime
> of the handle map.
>
> 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.
Plus, you'd have to be able to change the interrupt table, not just a system
call table entry, since NT goes through a currently unimplemented interrupt.
> 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?
I rewrote the userspace interface to work this way, giving me 10%-20% extra
performance.
One thing that I had to be careful of though is how the corresponding
structures are laid out. Two BOOL arguments in a row in a function call
parameter list take 8 bytes, but in a structure take only two. So I came up
with something like:
#define __pad__ __attribute__((aligned(4)))
struct WiocCreateEventA {
LPSECURITYATTRIBUTES __pad__ lpEventSecAttr;
BOOL __pad__ bManualReset;
BOOL __pad__ bInitialState;
LPCSTR __pad__ lpName;
};
When any userspace stub function invokes the ioctl, it passes the address of
the first argument to the kernel, which casts it to the appropriate structure
type.
> PS. Perhaps you should ask Linus about reserving a syscall for
> Wine before 2.4 is released in order to miniminze support
> problems.
Yep... assuming we want to do this.
David Howells
