OSDev.org

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.

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!

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!

bellezzasolo wrote: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!

Indeed. If you create a microkernel, then there is a natural IPC barrier that syscalls go through. The kernel side objects then are stored in server processes. In a monolithic kernel, the handle concept is probably better as then the objects are mapped in shared kernel memory.

bellezzasolo wrote: 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!

In my design, most user mode syscalls are usable in device-drivers too. The only exceptions are syscalls related to user process handling that has no meaning in kernel mode.

As for access control, I don't have user accounts, and so access control has no meaning in my OS. Which is interesting once I get to implementing ext and ntfs, as then I can just ignore file & directory permissions and show everything.

Something similar is already being done by Windows NT.

There is an internal "object namespace" whose structure is very unix-ish, for example, "\Device\HarddiskVolume1" is a valid path within the NT object namespace. This is, however, only exposed as say, C:, in the Win32 APIs.

iProgramInCpp wrote:Something similar is already being done by Windows NT.

There is an internal "object namespace" whose structure is very unix-ish, for example, "\Device\HarddiskVolume1" is a valid path within the NT object namespace. This is, however, only exposed as say, C:, in the Win32 APIs.

There is no c:\device path in my Windows 10 at least, but I suppose they want to hide this from end users.

OTOH, devices were already added to the FS in MSDOS, so I don't see the news value in it. And things like comports are opened using special pathnames.

However, it doesn't surprise me that they "steal" bad ideas from Unix. I've completely removed the DOS device file support, and I'm not adding any new support for devices in file systems. Bad ideas should rest in peace.

BTW, I'm not going "everything is a file" either. That would be contrary to my "handles refers to objects" idea, unless I imply that all objects needs to have read/write methods, which certainly is not the case.

I even "ditch" the read method in my new filesystem as it would be a slow version of doing syscalls when they are not necessary. The new way to handle files is to issue map requests, not to issue read requests.