[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Supexec taking one VBL?



Hello!

Yes, writing driver is easy but imagine the instruction for running the demo -- before you run my demo, please copy
this xdd to freemint's sysdir, reboot, run my demo and pray it doesn't kill your system. If so, I'm sorry for next
reboot :)
Even if we builtin something into the kernel, your instruction is: if you 
don't have FreeMiNT version XXX running, please install it first before 
running this application.
Maybe this isn't such bad idea in general but I can't imagine how this could work for custom handlers, i.e. every
demo/game coder would want to use his own specific code in VBL. And even when we find a way how to do it, we're back
in the beginning -- such coder could write bad (leading to crash) code which will take whole kernel down and this is
the current situation with Super()-ised democode.
The problem is that you don't have an application, you write a demo and 
you need full control over some parts of the hardware system.
The hardware system is normally managed by the operating system, and, 
ideally, the user space applications don't have any access to the 
hardware [and, much much better, the applications are protected against 
each other through the MMU]).
This means that only the the parts of the operating system have access to 
the hardware [for example, the hard disc driver is also part of the 
operating system].
That means there is no 'clean' way to access the hardware, except the one 
over the operating system.
It's nice that you like to write clean and FreeMiNT friendly demo 
applications. I really appreciate this and like to help as I can. For lot 
of things this is easily possible without lot of work or overhead.
But running a part of your userspace application inside the operating 
system violates the rules. Even if we design a new system call we will end 
up with something like Super/Supexec or whatever (maybe with some more 
protection and checks, but if your handler crash you crash the system).
[ Btw. Super/Supexec and friends are from the (modern) operating system 
design absolutely bad things, they allow user space application to enter 
privileged mode and getting full control over the system. This is ok for 
TOS (designed 30 years ago). For FreeMiNT it makes the life much harder. 
Imagine what a stable system you get if you a) forbid Super/Supexec and so 
on and b) always run with memory protection enabled :-) You only loose 
some compatibility to lot of existing applications ;-) ]

Regards,
Frank

--
ATARI FALCON 060 // MILAN 060
-----------------------------
http://sparemint.org/
e-Mail: fnaumann@boerde.de