Does a kernel-free OS make any sense?

[Mickey93]

I've got this vague idea for a kernel-free OS that consists of an interrupt handler, a memory manager, a hardware prober and some other utilities. The hardware prober would be used to modify application source code upon install in order to configure the applications to access that specific hardware directly (or rather through the mediation of the interrupt handler etc.). The compiled application would incorporate all capabilities necessary to execute in the total absence of any OS in cases when multitasking is not required. Aside from the absence of commercial potential and the difficulty of coding the hardware prober, does this idea make sense?

 

[rcgldr]

What would be the advantage of this versus something like dos which includes interrupt handers and functions (in the case of a PC, called via INT instruction) to interact with the hardware or memory management?

 

[FactChecker]

I think that you are describing minimal kernel functions without kernel priority or protection. The question then is what to do when higher level software is built on top of that OS? You will not want a long computational loop to delay your interrupt handler so you will have to give parts of your OS higher, non-interruptable, priority. That puts you back with a kernel.

 

[Mickey93]

Thanks for that explanation. I had a feeling it was a bad idea.

 

[FactChecker]

If you are going to program your own embedded control software, your idea has merit. You would have complete control and can embed special purpose controllers in a minimal system. It's just that you would probably not want to build a large system on top of it or use it as a general purpose computer OS. These days there are cheap single board computers that can support an advanced OS. And field programmable gate arrays (FPGA) have taken over a lot of the specialized hardware controller tasks.

 

[rcgldr]

Thanks for that explanation. I had a feeling it was a bad idea.

It's not a bad idea, since this is how various version of DOS work. You need some method of intercepting interrrupts, such as replacing interrupt vectors that point to handlers. The application(s) would need to create some internal method(s) to synchronize between interrupt driven code and the main level code. Games that run on DOS often have the equivalent of a mini-kernel in their code, in some cases, pre-emptive, prioritized, multi-threading.

 

[FactChecker]

It's not a bad idea, since this is how various version of DOS work. You need some method of intercepting interrrupts, such as replacing interrupt vectors that point to handlers. The application(s) would need to create some internal method(s) to synchronize between interrupt driven code and the main level code. Games that run on DOS often have the equivalent of a mini-kernel in their code, in some cases, pre-emptive, prioritized, multi-threading.

Interesting. Is that a way that a hard (clocked at about 50 Hz) real-time process could run on a Wintel machine? Would it allow the process to sync up with an interrupt coming in?

 

[rcgldr]

Is that a way that a hard (clocked at about 50 Hz) real-time process could run on a Wintel machine?

One method for running code at a fixed frequency is to monitor a high frequency clock. Here is example 32 bit windows code that includes Sleep(1) calls. For a single threaded application, the Sleep(1) would not be used. For MSDOS in 16 bit real mode, timer 0 runs at 1193180 cycles / second and can be used as the high performance timer. By basing the delays off an original reading of the timer, there's no drift over a long period of time.

/* code for a thread to run at fixed frequency */
typedef unsigned long long UI64;        /* unsigned 64 bit int */
#define FREQ    400                     /* frequency */
DWORD    dwLateStep;                    /* late step count */
LARGE_INTEGER liPerfFreq;               /* 64 bit frequency */
LARGE_INTEGER liPerfTemp;               /* used for query */
UI64 uFreq = FREQ;                      /* process frequency */
UI64 uOrig;                             /* original tick */
UI64 uWait;                             /* tick rate / freq */
UI64 uRem = 0;                          /* tick rate % freq */
UI64 uPrev;                             /* previous tick based on original tick */
UI64 uDelta;                            /* current tick - previous */
UI64 u2ms;                              /* 2ms of ticks */
UI64 i;

    /* ... */ /* wait for some event to start thread */
    QueryPerformanceFrequency(&liPerfFreq);
    timeBeginPeriod(1);                 /* set period to 1ms */
    Sleep(128);                         /* wait for it to stabilize */

    u2ms = ((UI64)(liPerfFreq.QuadPart)+499) / ((UI64)500);

    QueryPerformanceCounter((PLARGE_INTEGER)&liPerfTemp);
    uOrig = uPrev = liPerfTemp.QuadPart;

    for(i = 0; i < (uFreq*30); i++){
        /* update uWait and uRem based on uRem */
        uWait = ((UI64)(liPerfFreq.QuadPart) + uRem) / uFreq;
        uRem  = ((UI64)(liPerfFreq.QuadPart) + uRem) % uFreq;
        /* wait for uWait ticks */
        while(1){
            QueryPerformanceCounter((PLARGE_INTEGER)&liPerfTemp);
            uDelta = (UI64)(liPerfTemp.QuadPart - uPrev);
            if(uDelta >= uWait)
                break;
            if((uWait - uDelta) > u2ms)
                Sleep(1);
        }
        if(uDelta >= (uWait*2))
            dwLateStep += 1;
        uPrev += uWait;
        /* fixed frequency code goes here */
        /*  along with some type of break when done */
    }

    timeEndPeriod(1);                   /* restore period */

 

[SixNein]

I've got this vague idea for a kernel-free OS that consists of an interrupt handler, a memory manager, a hardware prober and some other utilities. The hardware prober would be used to modify application source code upon install in order to configure the applications to access that specific hardware directly (or rather through the mediation of the interrupt handler etc.). The compiled application would incorporate all capabilities necessary to execute in the total absence of any OS in cases when multitasking is not required. Aside from the absence of commercial potential and the difficulty of coding the hardware prober, does this idea make sense?

You should start with trying to define a problem in which your operating system would exist to solve.

For example, certain applications need to run in a certain amount of time, i.e., braking software on a car. Paging systems and so forth are often too random to give these time guarantees. You might have a page miss that adds unexpected delay.

So one idea is to build an operating system design to meet the needs of applications like the above.

 

[FactChecker]

One method for running code at a fixed frequency is to monitor a high frequency clock. Here is example 32 bit windows code that includes Sleep(1) calls. For a single threaded application, the Sleep(1) would not be used. For MSDOS in 16 bit real mode, timer 0 runs at 1193180 cycles / second and can be used as the high performance timer. By basing the delays off an original reading of the timer, there's no drift over a long period of time.

Thanks!