> Patrik Stridvall <psÉleissner.se> 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.
Yes, sure but as the benchmark has not much to do with the real
world, it is not a very large problem for most applications.
> > 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?
Yes, through a (or rather several) loopback mount.
> If so, don't
> forget: (1) the windows registry spans several hive files,
I know. But that if not possible to autodetect it
can be specified as an option to mount to
specify which is which.
> (2) hives can be
> added by user processes,
Hmm. Not sure. However that is problably rare
so I'm not sure we need to support that.
> (3) what about change notifications,
That is something that is supposed to be handled by the
special API through the special wine syscall.
OK, handling it internally in the kernel is perhaps not
trivial, but it can't be handled in user space.
> (4) what about
> dynamic data,
Well, the proc filesystem handles that. I can't
imagine it will be a problem.
> and (5) what about meta-data (type, etc.).
Well, other filesystem (like NT ACL:s or ext2 attributes)
have special attributes so I don't imagine it will be
a problem.
Of course you can only access them through the special
wine syscall, but that is a user space issue.
Reminds me perhaps with a kernel space server we can
speak with the NTFS filesystem behind the scene to
access the special NTFS features like ACL:s.
> 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.
Yes.
> > 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.
True. It might be messy but it is not completely certain that
it will be that bad. Try and find out.
> 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.
Perhaps.
> > 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.
Of course.
> Maybe attaching
> it to the
> exec_domain/personality stuff.
No, I don't think it has anything to with exec_domain/personality.
A WineLib application is supposed to be a normal application that
simply uses a library called WineLib. Wine is an "interpreter"
that used WineLib to run Windows executables.
Normal syscalls that a WineLib application uses should work like
it does for any normal Linux application.
> 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.
What happens if the module goes away?
The application segfaults I hope.