Daniel Pittman <daniel@rimspace.net> wrote:
> *blink* I confess that I can't see that much of a requirement for the
> ptrace stuff, but I take your word for it. :)
I was under the impression that the wineserver used ptrace() to retrieve
argument data to requests such as CreateFile(), but thinking about it, that
can't be so, since that'd mean you couldn't strace a wine program, which you
can.
It must instead pass all the argument data either by socket or by shared
memory (I'm not sure which offhand).
It does, however, (at least, I think it does), use this for debugging support,
but that's a special case.
> > Secondly, the client (wine) just has to issue a syscall that looks
> > exactly like a Win32 registry function, how it is handled is hidden by
> > the kernel.
>
> Not really something that I would have thought was needed -
> specifically, the userspace libraries that the process was dynamic
> linked to would have been the place to do that, I thought.
I suppose this is more of an implementation detail, but it's primarily why I
added an RPC mechanism.
> > Thirdly, registry functions should issue system handles, as is done on
> > Windows. If system handles move into the kernel, then registry handles
> > should do too. This also means registry change notifications can be
> > implemented by system handles that WaitFor*() functions can deal with.
>
> That, however, is a convincing reason.
And that's why I wanted a kernel interface to the registry stuff, for which
the RPC mechanism was added.
> IIRC there are not any waitable GHI objects, precisely because under
> Win32 the GDI is a userspace library that does most of the magic
> internally and then, finally, requests that the server does something.
>
> Like sockets, the GDI isn't actually a Win32 kernel thing, it's a Win32
> userspace wrapper that makes the minimalist kernel support more
> palatable.
However, I could make a Window a waitable GDI object... implementing
GetMessage() as Wait, GetAsync.
What I'd need to do is make it possible for the RPC server to create
signallable handles of effectively user-defined type that can be issued by and
passed through RPC calls. Hmmm... I'll have to think about that, but I'll
probably have to do something along these lines to support registry change
notifications.
> > Now there's an idea... Have the local X server as an RPC server,
> > handling wine GDI calls directly *grin*. Then I could hide all the GDI
> > stuff behind syscall stubs in the same way. This would allow me to
> > implement a lot of the NT Native API.
>
> Well, that's a point of view thing. The native NT API isn't anything
> beyond kernel32, as such. Certainly, the GDI isn't part of the core API
> and, in some cases, MicroSoft do release or use the NT core without the
> GUI system, at the least.
But it is there. I think it may use WinStation handles somehow, but I don't
know for sure without a bit of disassembly work.
> Anyhow, I am hardly an expert on the area, but... I would have avoided
> putting stubs into the kernel anywhere that it was possible and used the
> userspace dynamic Win32 libraries to do most of the work.
It depends on what you want... What I'd like is basically a range of Win32
system handles that map to (or apparently map to) kernel services. I'd also
like these to be available for ordinary Linux programs to play with if they
want to.
However, I think I might be able to see what you mean... I could implement an
RPC server, say, that has one exported operation: do registry op. Then have
all the registry operations mapped down by a userspace library to the RPC
invocation call to a single operation on that particular server.
> OTOH, I would also have implemented the WaitFor* set as a wrapper over
> select, with the kernel module providing suitable file descriptors for
> adding to the set that you waited for.
This is one of the things I was trying to avoid:
(1) select and poll do not implement the entire range of things you can do
with WaitForMultipleObjects;
(2) the struct file+struct dentry+struct inode complex is incredibly heavy
for most of what I want to do (though does have advantages);
(3) Linux file structures do not hold enough information to support
CreateFile (access & sharing interactions).
> We have fairly different views on how this stuff would hang together
> and, in all likelyhood, mine are based on incorrect assumptions. :)
True... Isn't it nice when you can provide what API's you want rather than
having to make do with whatever is dictated to you. Yes... I'm implementing
some of the Windows system APIs because I'd like to have that functionality
available under Linux running as fast as possible, not because it's the only
one worth using:-)
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/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:23 EST