I think under the hood COM works much the same way - after all, when an application calls a method on a COM object, that object can be in a different process, so the actual implementation is a proxy class that marshalls the call through an IPC mechanism - indeed its possible to use over a network!rdos wrote:bellezzasolo wrote: I think that is ok, but you shouldn't export class structures between kernel & userspace. Handles are a kind of object reference, and in my design, operate a bit like objects. I have some 20 different handle types that maps closely to userspace classes. In my classlib, I actually provide C++ classes for userspace to make the OO integration better. However, the syscall interface use a handle to identify the kernel object, and then pass parameters in registers. The userspace object pointer is not sent to kernel space since it easily changes and becomes incompatible.
This way of implementing an OO interface has some definite advantages. It particularly enforces encapsulation since userspace doesn't have access to internal object fields, and these can only be updated with proper methods through syscalls.
Implementation across the kernel boundary probably ends up sharing very similar concepts.
My thought with doing it that way is that you can offer the same API to kernel mode as to user mode - obviously access control needs doing. Whether you could implement user mode drivers the same way is a tantalising question, hopefully I'll get to explore it!
