Design approaches

[mr. xsism]

what is mre effective and useful:
having an OS that freely allows hardware access, no memory protection, nor io port protection? Or an OS that restricts the above.

Is it possible to allow hardware access for coders while at the same time protecting the system from accidental or designed failure?

I beleive that the first scenario is ideal for programmers but unstable while the 2nd is great for avg joe end users yet restrictive.

How possibly close can you intermingle this situations without defying physics?

[Pype.Clicker]

How possibly close can you intermingle this situations without defying physics?

hehe
[url=http://www.thinkgeek.com/interests/retro/65a4/]
So you don't respect any laws ? not even Gravity
[/url]

If you have enough TSS to play with, you can theorically open some ports to a program (allowing it to play directly with a restricted part of the hardware) and with appropriate memory management support, you can open memory regions aswell ...
This means that you could have the printing server talking directly to the printer if you wish so, the whole stuff happening at DPL3 ...

That's what i'll try to do with Clicker.

Other things like disks are more complicated to share. For instance, if you offer access to ATA secondary master, you cannot prevent it to access the secondary slave aswell ... And do not even try to block the client from accessing /dev/hda1 if it can access the /dev/hda disk... (should be obvious)

[Tim]

An OS with no memory protection is hell to develop for. You ever tried writing DOS applications?

If you want to turn off memory protection, you'll still need some measure to stop applications from accessing bad pointers. Mistakes in applications are a fact of life.

[Pype.Clicker]

An OS with no memory protection is hell to develop for. You ever tried writing DOS applications?

If you want to turn off memory protection, you'll still need some measure to stop applications from accessing bad pointers. Mistakes in applications are a fact of life.

very true ... even at kernel level where everything is theorically possible, you quickly come to the conclusion that you need to enforce C commandment #1: "thou shalt not follow the NULL pointer"

So you'll be installing tricks to force your kernel to report a fault when it tries to access NULL, otherwise, inexistent objects will suddenly appear to be objects which content varies randomly...