Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: bloodline on November 17, 2010, 10:11:32 AM
-
Hey there, google translate isn't being very clear here... What is Linus getting at?
https://groups.google.com/group/sfnet.atk.sodat/msg/9d730043aa229345?hl=fi&dmode=source
-edit- changed topic title to reflect the current thread.
-
I can't help with the Finnish translation but I think he's claiming that Amiga processes have to 'play nicely' - CPU time can't be taken away from a running process without the cooperation of the process. I'm not sure how true this is?
Hopefully someone who understands Finnish can clarify this ... :)
-
Hey there, google translate isn't being very clear here... What is Linus getting at?
https://groups.google.com/group/sfnet.atk.sodat/msg/9d730043aa229345?hl=fi&dmode=source
Quick'n'dirty translation:
That's a no.
Amiga has a "pseudo-pre-emptive" multitasking, which Amiga-people call pre-emptive, but which certainly isn't that. In this regard WinNT is lightyears ahead.
TRUE pre-emptive multitasking means that the operating system can pull the CPU under the program and run some other program in the meanwhile. Amiga doesn't have such a multitasking, partly because of the lack of memory protetion. Whatever application can take over the system fully and prevent the multitasking.
The Amiga multitasking is co-operative because it requires that the applications agree to the multitasking and aid it (that's what the "co-operative" means anyway, check the dictionary, although I guess it'd better be a english one ;). QED.
Agreed, writing such an application requires some nifty coding (but not that much) or some bad luck (again not that much either). For example with Win3.11 writing such application is magnitude easier.
But in _real_ operating systems (which I suppose includes NT) you can't create such an application without the root permissions.
His point is that no user application should be able to lock up the multitasking without explicit permission from the super user. He has issue with application such as:
int main(void) { Disable(); for(;;); }
-
Many thanks Piru,
I see his point, but I feel his issue is a security one rather than a multitasking one. I think a co-operative multitasking system explicitly requires a task to give up the CPU... In AmigaOS a task as to explicitly "request" (as if disable()/forbid() are optional for the OS to action) that CPU is not given up.
I submit linus is wrong :lol:
-
Surely a pre-emptive multitasking OS requires that a task can be pre-empted, that is can be made to vacate the CPU by normal switching operation the kernel. If you've disabled interrupts, then you've basically shot down the kernel system that enables pre-empting to function.
This is a security issue, not a cooperative versus pre-emptive one.
I submit that bloodline is correct :)
"I say, Mr. Torvalds, what would you know about kernels anyway?!", he said, posting from his linux box... :lol:
-
I also disagree with Linus regarding Monolithic and Micro Kernels... I guess that's why I'm looking for Darwin solutions to replace my current linux based boxes (not an easy task).
-
I dunno, the arguments around monolithic v microkernel have some good points on both sides. Also, Darwin is not what I'd call a microkernel. At best it has elements of both and is probably best described as a "hybrid", which may be no bad thing.
I guess that's why I'm looking for Darwin solutions to replace my current linux based boxes (not an easy task).
Why, do they not do what you require?
A lot of these design arguments are very interesting but in the real world, if it isn't broken, why fix it?
-
I dunno, the arguments around monolithic v microkernel have some good points on both sides. Also, Darwin is not what I'd call a microkernel. At best it has elements of both and is probably best described as a "hybrid", which may be no bad thing.
Actually I agree, the argument for and against either design is compelling either way! But from a philosophical view point I prefer microkernel... Though I fully understand the real world does not fit the ideological one :)
Yes, Hybrids are the best real world solutions in almost all situations!
Why, do they not do what you require?
A lot of these design arguments are very interesting but in the real world, if it isn't broken, why fix it?
Goodness me no, Linux meets and exceeds all requirements, but since I am running these boxes/boards as a hobby I would prefer to fit my ideology rather than practicality... I guess the same reason people still want to run PPC CPUs even though they offer no real world advantage.
-
I also disagree with Linus regarding Monolithic and Micro Kernels... I guess that's why I'm looking for Darwin solutions to replace my current linux based boxes (not an easy task).
Not Darwin based, but very cool all the same.
http://genode.org/
-
Goodness me no, Linux meets and exceeds all requirements, but since I am running these boxes/boards as a hobby I would prefer to fit my ideology rather than practicality... I guess the same reason people still want to run PPC CPUs even though they offer no real world advantage.
Ah, righty-ho. Carry on then :hammer:
-
@Matt
Have you played with Haiku (http://www.haiku-files.org/cd) much?
-
@Matt
Have you played with Haiku (http://www.haiku-files.org/cd) much?
Actually no, I did run BeOS PE5 for about 3 months as my main OS... But while I did like some of the ideas behind it, I was never grabbed.
The Genode thing you linked me to, look much more interesting.
BTW, I like darwin for a few reasons: it is built for x86 and ARM (my two hobby CPUs), it's a microkernel (well more a hybrid) and it has a fully featured Obj-C runtime that suits my predilection for Obj-C at the moment :)
-
...that suits my predilection for Obj-C at the moment :)
Pervert :lol:
-
Pervert :lol:
You know it!
-
Actually no, I did run BeOS PE5 for about 3 months as my main OS... But while I did like some of the ideas behind it, I was never grabbed.
The Genode thing you linked me to, look much more interesting.
BTW, I like darwin for a few reasons: it is built for x86 and ARM (my two hobby CPUs), it's a microkernel (well more a hybrid) and it has a fully featured Obj-C runtime that suits my predilection for Obj-C at the moment :)
The BeOS API is a thing of beauty, it is the hardest of hardcore pr0n for the C++ aficionado! :)