OSDev.org

I guess I'm a bit backwards by all accounts. I spend a lot of time writing (user-space) database drivers in C++, so I look forward to doing kernel dev in C as a nice change of pace.

I've decided to go with C because I'd rather focus on the OS-centric implementation details rather than the language/compiler-centric ones. Also, I'm planning to go with a microkernel architecture, so a lot of the "interesting" code will be in user-space anyway, where C++ is no problem at all. This is a major limitation of the "kernel module" approach taken by Linux and NT/2k/XP -- too many restrictions on the driver developer. I think if you want robust drivers you have to let the driver devs focus on the hardware and not the crazy implementation details of the kernel (including lack of support for C++).

For example, one pitfall of using C++ I've read about is in the case of pageable kernel-mode drivers. If you use virtual functions, the compiler might decide to put your vtable somewhere where it shouldn't be (i.e. -- where it could get paged out at the wrong time). Yikes! I'm sure there are lots of evil details like this lurking around. I think I'll stick with user-space for C++.

Colonel Kernel wrote: For example, one pitfall of using C++ I've read about is in the case of pageable kernel-mode drivers. If you use virtual functions, the compiler might decide to put your vtable somewhere where it shouldn't be (i.e. -- where it could get paged out at the wrong time)...

Now you woke my curiosity. Aside from the fact that I consider the idea of paging out drivers a bit strange - what would keep the fault handler from paging in the vtable on demand? I don't quite get it...

Aside from that, you're right, C++ and microkernels go along together well because you're minimizing the amount of code where you have to pay "special" attention (disabled exceptions etc.).

If the page fault exception handler calls a function to swap in the page via a virtual function and that vtable is swapped out, I guess then you have a problem
What do we learn - unswappable memory is necessary, as in C kernel a pointer to the page directory might be swapped out then as well

The idea behind a full c++ kernel (and any kernel as long as reliability is concerned) is that you know exactly what is where, and when it is called. If you have even 2 bytes of unknown, you're at a dead end. You can of course use this to lock the exact parts that need to be locked so that the swap system always keeps functioning, even though it may swap other parts out. This does require being able to lock memory (yes DennisCGc, this is a place where those 3 bits are of use).

The VTables are class specific as far as I know, and will end up in a section you define for it. Just lock the VTables in memory for those purposes.

However, the same basic principle applies to C kernels, too.
That is no C++ specific problem.

Legend @ Work wrote: However, the same basic principle applies to C kernels, too.
That is no C++ specific problem.

any kernel as long as reliability is concerned

Yes, if you swap out half the kernel in a monolithic system including a page in use by your FS driver you're screwed.

Candy wrote: The idea behind a full c++ kernel (and any kernel as long as reliability is concerned) is that you know exactly what is where, and when it is called. If you have even 2 bytes of unknown, you're at a dead end.

This is what I mean by having to deal with very compiler-specific implementation issues. I'd rather focus on the kernel than the tools I'm using to write it. No doubt C++ kernel development is possible, but I consider it at least as much a learning exercise about the output of C++ compilers than about kernel implementation.

Now you woke my curiosity. Aside from the fact that I consider the idea of paging out drivers a bit strange - what would keep the fault handler from paging in the vtable on demand? I don't quite get it...

In terms of a driver in a monolithic kernel, it might be possible for the ISR to try calling an object whose vtable is paged out. Page faults while running ISRs == bad. Of course, the solution is to lock everything in memory that will be used by the ISR (or any other "sensitive" bits of code like the DPC handlers in NT), but you have to know what to lock... see above.

Ah, OK. I never considered calling objects from my ISR; that's why I didn't consider the possibility of #PF-in-ISR.