OSDev.org

I have an pretty hard question to be answered. I have made some reaserch on the area of developing an OS and kernel in C++. The information I have found on webpages here around tells that there are some problems to overcome with new/delete and some other stuff. I do believe that this is not the difficult part (yes it is difficult but there are something worse). And now to the problem!

How to share classes between privilegi levels!! When you make an OS in C it's just to make callgates for the functions you want to share from the kernel. But how do I share classes. A class is not only a function you can make a callgate for. It is a piece of memory. Say for example that I have a class in the kernel that is a device driver, I want to make a call to that driver, and I do so. But before I can do so, I need a pointer to that class so I can access it, which the protected mode prevents me from!!

Anybody have an idea about how to do that????

I have read some C++ OS webpages to see how they did it. For example the "Choises" operating system. In that system they declare some classes and with the keyword: proxiable
But that is not an ISO/ANSI C++ keyword. Probably the author had to modify the compiler.

// Krillzip

Personal Opinion: Operating Systems should be developed in 'lower-level' languages such as C and Assembly.

I think it's no problem to develop an OS in C++. I'm doing so currently.
But I thing there is no way to make calls to class-functions through priviledge-levels. If you want to have a C++-Api you have to make your libc in c++. This lib must then translate each call to a class-function to an Api-Function (e.g. a Call-Gate).
If you want an example, look at the AtheOS homepage. I think they are developing a C++-frontend for their API.

Well then i have to take a deeper look at AtheOS.
Do you have any site for your os yet so that I can take a look?

// krillzip

Atheos can be found at www.atheos.cx  I've found that site to be fairly tempormental, though, so if you can't get to it now, try again later.  It's definitly worth the hassle.  AtheOS has an impressive set of features, and already has useful applications being built for it.

As per your first question, though... do you really need to access objects through privelege levels?

I assume what you wish to do is have kernel code protected from the application level, but still callable by them... right?  Perhaps you could put your C++ code in a shared memory space, and utilize protection through the pager, and not privelege levels.

In other words, it can still be protected through the paging mechanism by setting it read-only, and the applications can still execute it.

Just a thought,
Jeff

Never thought about that worth to check out. Maybe I can have a page for each Manager class to load.

I have to think on different models on how to do it. What is important is that the class has the possibility to behave like it was cout or cin but it is a part of the kernel. Maybe there are a lot of possibilitys to make this?

Another problem could be name mangling, because it's not standardized in C++, maybe I should send a mail to Mr. Stroustrup.
                
// Krillzip     ;-P

It's actually not that hard to do. The thing you have to realize is that you can probably only do it for pure virtual classes, because most optimizers will "embed" part of the class into the client code while during optimizations. That said, you have to look at how the C++ compiler handles virtual methods. Most build a pointer table in memory, called a vtable, then for each invocation, pick the correct pointer and jump to it. The pointer to the actual object will be pushed on the stack (by the compiler). So what you have to do is replace those virtual table pointers with a pointer to a function that first pushes a function code on the stack, the makes a system call. Now, that system call can examine the object pointer, and the function code, go get the correct vtable, find the correct method (using the function code) and call it. If you do standard x86 style system calls, the user stack will be copied to the kernel stack, so if the stub system call does nothing but pop the function code, the stack will already be perfectly set up for the C++ class call, so you don't have to mess with anything further. The only real semantic difference now between this method and a standard virtual function call is that the class (in the kernel) has to be mapped read-only into user space so you can get at the v-table. There is a slightly different method, that requires more code, but less hackery with compiler-specific data structures. Instead of handing the userspace client a pointer to the real object (that lives in kernel space) hand it a pointer to a proxy class that lives in user space. Give this proxy class a pointer to the real class. Now, whenever the client makes a virtual function call, the proxy class will get it first, and it can invoke a system call, and hand the kernel the object pointer and function code. Then, another (class-specific) dispatcher in the kernel can look at the object pointer, and the function code, and invoke the correct method. In general, these are the only two ways to directly access classes in kernel space. Most object-oriented OSs don't do this, by the way. The kernel exports a standard C-like system call interface, and the objects live in userspace and make use of these system calls.

That sounds most interesting yet. That is what I wanted to do. Why I want to call classes si to keep the good C++ syntax, like you have a driver or API that
is a C++ class. I want the calls to be programmer friendly like this:

Screen & Diplay = Kernel.getDriver("ScreenDriver");

Image & myimage = *new Image();

// ... image draw code

Image.SetCoord(100, 100);
Display << Image;

If I can call class functions thru privilegi levels, I can access drivers like it was a usual:

cout << "Hello world" << endl;

Thats why I want to do this.
With this I can make my Object Oriented Operating System filosophy come true.

"si" at line 1 should be "is"
"filosophy" at line 18 should be "philosophy"

krillzip

Sounds cool. But one problem: operator << is not a virtual function and can't take pointer types (which you need for abstract base classes), so you'll have to write wrappers.

Say DisplayInternal is the display object, and ImageInternal is the image object. These should have regular virtual functions like DisplayInternal::Draw(Image * img);

Now, you'll have to define classes Display and Image, which internally have a DisplayInternal * and a ImageInternal *. Then you'll have to define some wrapper functions

ImageStream & operator <<(Display & lhs, Image & rhs)
{
lhs.Draw(rhs);
}

Then, Display::Draw would have to do:

internalDisplay->Draw(Image->internalImage);

Yeah, know about that problem!
But as you explained, it can and will be solved.
This is just a minior problem.