My thoughts about revision 0.0

[ANDREASA@dhhalden.no]

B. Resource requirements
As for the vague estimate on hardware, concerning the harddisk. Preferably
under 5 MB for the basic system. Now saying only 25% for a minimum hardware.

Utilization of S-VGA. Most people have S-VGA, so there will seldom be
necessary to buy extra hardware. Few programs utilize svga because of the
actual lack of a hardware standard, but that shouldn't be a major problem. Not
yet anyway...

C. Platform Issues

I must say I don't know very much about the 680x0 series, but I like the idea.
As you probably now, there will be no 68050, instead Motorola is going to
launch their 68060 as their replacement for 68040. My question now. How large
differences will there be in the processor architecture, concerning the
succesor and the already existing ones. Not because it has very much with the
issue as such, but it might come to have.
What do you now, and how could it affect our work?

Then Dennis mentions the Mac. Is it possible to replace the MacOS. Isn't it a
rom based OS?

D. Design Principles
When it comes to design principles. I see the point Fare' comes with, but
if you take a look at the Protection Hierarchy you could see that it won't
make any larger difference what language is used. For us, as programers of
kernel parts, device drivers etc. we need the flexibilty of C++, beacuse of
the fact that it is close to the hardware. If we enforce the rule;
"No tasks at the 'user' level (see part E. of Introduction) can manipulate
hardware directly. The only way a program in the 'user' level can access
hardware is through objects in the lower Privilege Levels"
I'm using Privilege Levels (PL) the same way as the Intel literature does,
with lower meaning the layer below.
Then it won't matter what language you use, because no one will be able to
use the hardware directly, without makeing their own device first, and devices
are public.
Do you get my point???

E. Protection Hierarchy
Why not four PL levels? I agree with the one you suggested, but on the other
hand, I prefer having higher priority for devices needed for the OS function-
ality, than equal for normal extra device drivers, and OS device drivers.
That would make things harder to change at will, in a released product.
And others won't be able to do it.

Section III
2. Semaphores
You must have a way of identifying the resource you are going to use the
semaphore on. A resource Handel (ugghh, I hate them :-), a filename, etc.

3. Timers
There must be two timers. One that measures the time the task use, and
one that measures the total real world time.
In some programs you might want to know how long time the program needed for
task, and if you measures the elapsed time, you must subtract the time that
went to other tasks and to the kernel.
Then you have the other situation, where you want to measure time as the
quantity the user have to live with :-)

That's about it. Some ideas, suggestions, enhancements and questions.

Have a nice day.

Arff

BTW. I liked 'Midgard' too, if you want I can post a .wav file with the
correct pronuncation (?) to you :-), I live there, you know....:-)
Greatings from the land where polar bears walks on the streets...

sig.'s in for 1000 miles service
        --Andreas Arff          andreasa@sofus.dhhalden.no--