David Kanter (dkanter@realworldtech.com) on 5/9/06 wrote:
---------------------------
>Kernel_Protector (kernelprotector@yahoo.com) on 5/9/06 wrote:
>---------------------------
>>According to my view, since its a kernel, its design should be planned good.
>>variable codes(codes which interact with hardware, daily new hardwares appears)
>>Vs fixed codes(or not frequently changing codes and 100% >reliable codes and does not deal with hardware)
>>only fixed codes should be running in kernel space with full priviledges and variable
>>codes should be running in user space.
>
>
>No amount of planning can substitute for seeing what is going on. If you try to
>freeze software in stone and never change it over the course of 10 years, you're going to be very very sorry.

Not completely, but you would be surprised. Those who have spent a lot of time in the world of windows are used to programs changing all the time. This is because many of those program and much of the OS is badly designed.

In Unix things have lasted much longer. The basic function call interface used today has few differences to that of the eighties, most of the differences additions not changes.

Some of the basic userland utilities have changed even less. (Though in my opinion some of them should have changed more than they have).

In general there is a principle that programs(and modules) can be split into two basic types:-
1. Code with a fixed requirement
2. Code with expanding requirements

Many programs, including OSes and most apps fall into class 2. Some though fall into class 1, drivers for example fulfill a fixed requirement, when the hardware changes a new driver is needed. This may reuse code from an old driver, but that isn't quite the same thing.

More modules than programs fall into #2. In large peices of software it's not hard to find files that have not changed in many years, or where the only changes have been bug fixes. These modules can generally be kept freer of bugs more easily than others, often the only "bugs" found in them are misunderstanding in the interfaces.

If the core part of an OS kernel could be brought into class #2 then that would be a great achievement, because it would make achieving high reliability for that part much easier. It may not be impossible, since the amount of functionality and code concerned may be only relatively small, say 20000 lines.

>>if IPC, Memory management those which has a complete programming which wont have
>>bugs(since the codes for these may be small and which wont have any frequent code
>>change) only runs in the kernel and everything else(remaining drivers) which might
>>have code change even daily runs in the user-level, will result in a good secured and reliable OS.
>
>Has it occurred to you that these functions might need to change over time?

This may actually be possible. All that is needed is for the base kernel to implement the absolute most general cases. Libs further down can translate this into interfaces for other programs.

It would be progress even if these things could change little.

>>regarding performance,
>>i like to say this...
>>i had a program which took 15 minutes to complete with a pentium II processor.the
>>same program took 7 mintues to complete with a pentium III processor. and it took
>>only 2 or 3 minutes in a pentium IV processor.
>
>Do you write code which can run efficiently (> 90% speed up) on N threads, for
>arbitrary N? If not, I wouldn't count on that any more.
>
>Besides, just because hardware gets faster isn't an excuse to write bad software.
>That's like saying that we don't need seat belts in cars since people tend to be
>healthier over time as nutrition and our understanding of the body improves.

As "blah" said, I personally would rather have safety and security than speed. Both would be preferable though.

I'm not sure this is such an issue anyway.

>>the performance will be increased by the hardware automatically as time goes on.BUT
>>will a kernel safety like microkernel be given by any >hardware automatically ???
>
>Is a ukernel really that much safer than existing operating systems? It seems
>to me that some systems like VMS, zOS and NSK all have up times as high as a couple
>of decades. Doesn't seem like safety's really a problem...

Many systems have been made safe and secure through extremely paranoid kernel programming. This is a legitimate engineering choice. But it causes many problems. Many of the operating systems you mention are primitive in many regards compared to more modern systems. That is their filesystems, syscall interfaces, threading etc leave much to be desired. They also support relatively little hardware.
This is because of the enormous care that must be taken in changing them.

The (possibly false) hope that microkernels give is that they may make it possible for more sophisticated systems -ones with the capabilities of say linux- to be similarly reliable.