OSDev.org

• We're talking about a really minimalistic microkernel -- no kernel-mode drivers or modules of any kind. This means all the code is written/maintained/known by one team (currently one person). It should also mean, in theory, that all control paths are well-known and behave predictably, especially in terms of memory usage.
• There are two kinds of object lifetimes in such a microkernel -- those that must persist between kernel invocations and those that do not (examples below).
• The kernel programming style used lends itself to small, transient, dynamically allocated objects (this is a big assumption that may be invalidated before I'm through).

• Dynamically allocated strings (rare, I know, but possible -- perhaps used when formatting output for debugging).
• Polymorphic objects that encapsulate behaviour within the kernel that varies at run-time. It's hard to think of a concrete example right now -- I'm early in coding and haven't fully forseen the need for such things. I'll just throw out one possibility -- imagine something similar to std::ostream in C++ that could output to either the screen (vgastream?) or a serial port (serialstream?), depending on whether a remote kernel debugger is active.

• Does anyone think this is workable?
• Does anyone think it is useful?
• If so, can you think of any more example situations in which it would be useful?

Candy wrote: Transient objects that are not for debugging:

buffers for disk interfacing
packet buffers for all things that send packets (mouse, network, keyboard, etc)
IPI storage
stuff like that

the general point I think you are trying to make is that you thought up persistent objects, that remain after a reboot. Am I correct or are you implying something else?

Colonel Kernel wrote: No, I used the term "persistent" somewhat loosely. The more important point is that there may be some things you might need to dynamically allocate for a very short period of time (i.e. -- for the duration of a single syscall, interrupt, or exception), and for these, the technique I described above would potentially be very fast and cheap to implement (if it works under all cases).

Candy wrote: For allocating small objects for a short period of time (during a single call, interrupt or exception) you can very well use the stack. Allocating from the stack on non-windows is order-1 in complexity, you substract what you want from ESP and it's yours.

void someFunc()
{
    // someFunc() decides what the types of foo and bar must
    // be -- not very flexible.
    FooSomething foo;
    BarSomething bar;

    foo.doSomething();
    bar.doSomething();
}


void someOtherFunc( int objType )
{
    // someOtherFunc() does not decide what the actual type
    // of the object is -- this is the caller's decision to make.
    ISomething* something = createSomething( objType );
    something->doSomething();
}

• I like OO design techniques, but I want to implement my ukernel in C, not C++ for reasons I've stated in other threads.
• There are techniques for polymorphism and encapsulation in C, but they typically require objects to be allocated on the heap or statically, then referenced only by pointer.
• Traditional heap management is expensive for small objects. I also don't want functionality that must be very reliable to have to rely on such a complex sub-system.
• General-purpose garbage collection is too expensive to implement in the kernel and would be big overkill. This means traditional heap management ala malloc/free is still necessary, at least for objects that must live for a long time (i.e. -- between kernel entry/exits).
• For short-term objects, it is possible to dynamically allocate them from a "mini-heap" in the same block of memory as the current thread's kernel stack, according to the scheme I've outlined above.
• The possible problem with this scheme is that the "mini-heap" and the kernel stack share the same memory block, which is finite in size.
• The finite size might be ok, given that we have a very small, closed system (ukernel with minimal features).

AR wrote:This seems to be exactly what you want

MyObj someObjStorage;
MyObj* SomeObj = &someObjStorage;
InitMyObj( SomeObj );

MyObj* SomeObj = createMyObj();
...
// Somewhere else...
MyObj* createMyObj( void )
{
    MyObj* newObj = (MyObj*) kfastmalloc( sizeof( MyObj ) );
    ... // init fields of newObj
    return newObj;
}

• There is no kfastfree() to be called -- all deallocation happens for you when the kernel returns to user space; and
• It doesn't use the run-of-the-mill heap management algorithms, it just uses a stack-like structure instead, which is really, really fast.

Colonel Kernel wrote:

Code: Select all

MyObj someObjStorage;
MyObj* SomeObj = &someObjStorage;
InitMyObj( SomeObj );

What I want is something that looks like this:

Code: Select all

MyObj* SomeObj = createMyObj();
...
// Somewhere else...
MyObj* createMyObj( void )
{
    MyObj* newObj = (MyObj*) kfastmalloc( sizeof( MyObj ) );
    ... // init fields of newObj
    return newObj;
}

MyObj SomeObj();
...
// Somewhere else...
MyObj::MyObj( void )
{
    // init fields of this, the pointer is called "this" here...
}

Candy wrote: As for me being a c++ proponent, try

Code: Select all

MyObj SomeObj();
...
// Somewhere else...
MyObj::MyObj( void )
{
    // init fields of this, the pointer is called "this" here...
}

This is equivalent to what your code does, but has even less fluff, is allocated on the stack and automatically calls a destructor too (so you can use heap-allocated stuff etc. in the object, and be signalled when you go out of scope).

How is your solution better than this?

IObj* someObj = createObj();
...
// Somewhere else...
class MyObj : public IObj {...};

MyObj::MyObj()
{
    // init fields of this, the pointer is called "this" here...
}

// Somewhere else again...
IObj* createObj()
{
    // Maybe it creates a MyObj, maybe it creates some other
    // implementation of IObj. Either way, it must use new...
    return new MyObj();    
}