On Tue, 8 Jul 2003 12:49, Kelly Leahy wrote:
Are these calls your own creation or do they already exist in some form in the server?
They're my own creation. I'm looking more at the abstract regarding what would be necessary rather than implementation at this stage. It may be that there's a fundamental flaw I've missed, in which case I'll have to think of some entirely different approach.
Why does the "get object data" call not have an offset, but the "set object data" does? Is offset intended to allow incremental updates of the object's data?
That was the idea, and there's no particular reason why the calls aren't symmetrical other than that's the way I thought of them.
Do you need a "get acl" function, or is the ACL going to reside in the user's space (or in the object data?)?
A "get acl" may be necessary, depending on whether the user space code needs access to this information of course. One reason user space code may need access is if one process is if more than one process can modify the ACL. The ACL may be the basis for the NT security APIs that deal with ACLs, which would definitely require a "get acl".
If you're going to allow an "attach to kernel" functionality, shouldn't it return an opaque handle that is passed to all other functions so that the same client can make calls on different instances of the kernel?
Possibly. I was only thinking of the use of an ordinary client process, which only needs to be able to attach to one logical Wine kernel.