| [Forum] Amiga Exec kernel rewritten as exokernel | Link |
|
Amiga Exec kernel rewritten as exokernel : Comment 3 of 141 | Posted by Alkis Tsapanidis (Registered user) on 19-Feb-2005 21:13:24 | Ok, you started a new thread so I will reply to you here.
> For monolithic kernels and microkernels, but not exokernels.
> Exokernels remove a great deal of what would be normal talk in between kernel and apps. Because
> much of what is normally found in a monolithic or microkernel...is moved to user level.
First of all, you do not seem to be able to understand very basic operating system workings.
About Linux drivers... It doesn't matter what an exokernel does, it can dance if it wants to, no Linux drivers will work if you do not provide them with ALL APIs and resources they use. This means that you WILL need to write that huge wrapper. Now, you say that exokernels remove the need for that and that.
Ok... Sure... Now, let me ask you something... Are Linux drivers made for an Exokernel? Nope. They will use certain APIs to provide their services. The system MUST provide those services to the applications which means that it will have to wrap the APIs to a common one. Sure, this would work... It would just be INCREDIBLY slow... And that is without adding the overhead of having to save the state of all hardware on every context switch, since you insist on having every driver on each task specific libOS.
EyeAm, this is not new technology... Giving hardware access to apps is going 15 years back in time and adding protection and some EXTREME overhead. Also, the "Linux driver wrapper" *MUST* be GPL and must *NOT* be part of the OS if you don't want the OS to be GPL. Else, forget it. Linux drivers are statically linked kernel modules.
> *The next Amiga OS should be 64-Bit.
That's easy.
> *The next Amiga OS should be built on an exokernel.
I can debate this any time.
> *The next Amiga OS should utilize Linux drivers (allowing for the running of Linux by option, and of > course utilization of any hardware cards drivers have been writte for).
I already stated why this isn't possible.
> *The next Amiga OS should be--and can be--fully backward compatible with all previous versions of > Amiga software and OSes.
It cannot. Amiga software need access to all memory. If you use your exokernel approach, having a different AmigaOS for each task, tasks cannot communicate with each other, cannot access data in other tasks except if the, to use the "exokernel wording", mutual trust mode is used. Guess what... this defeats the purpose of having memory protection in the first place, the system will not crash with
dodgy apps, every single Amiga application will.
> *The next Amiga OS should support SATA, USB 2.o+, Firewire, and the latest in hardware standards.
The current AmigaOS does support SATA and USB 2.0.
> *The next Amiga OS should be able to use PC disks as 'Amiga drives' and recognize classic Amiga
> disks in those drives; and be able to read/write to and from those in Amiga format. (see Catweasel)
> *The next Amiga OS should be able to use PC disks as PC disks, too. (see CrossDOS)
All things you stated are already possible... Floppy disks are dead, forget them.
> Maybe you see where I'm heading now? :) An uber Amiga. A scary Amiga to competitors. Why, if
> Amiga could run WINE...you know, WITHOUT WINDOWS...all the more reason to tempt people back,
> and *with* programs they're used to, for the most part.
I do know where you are heading... It's not feasible. It's just a pipe dream with *WAY* too many flaws in the design, the biggest of which is the exokernel design itself, having to save the state of everything in each task switch, getting us back to the days of co-operative multitasking and *hardware* crashes.
Let me give you an advice... You seem to be VERY passionate about what you want to do. You should study some *real* operating system design and apply your ideas AFTER you do that. Your current design is way too flawed.
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 4 of 141 | Posted by EyeAm (68.59.54.5) on 19-Feb-2005 21:57:12 | In Reply to Comment 3 (Alkis Tsapanidis):
I suggest you do some study yourself, on exokernel design. You might learn what you obviously do not know. I know these ideas will work. You have only offered contrived 'flaws'. If you can't work around such things, you shouldn't be programming.
This is the direction I am going with my own operating system, too; but will of course be able to do all of this ahead of that, simply going the Suse/Wine/UAE route. It already runs this stuff. How can you say it cannot, when it already does? ;-)
Amiga programmers need to wake up and smell the coffee. They are aiming far too low--and what they'll wind up producing is something mediocre that will be priced way too high, and won't sell.
There are too many people in the community that say "can't". What have you people really produced that is worth anything? Nothing. All you seem to do is whine and gripe and put down other people's good ideas. It's back to ego and money, I suspect.
Not for me. I know this will work. I'm going this direction. And my operating system is going to run everything Amiga. The patents have begun running out, and all of them will be public domain by 2010, according to Fleecy. Just five years away. :)
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 5 of 141 | Posted by EyeAm (68.59.54.5) on 19-Feb-2005 22:03:17 | By the way, you should have just posted a link to the rest of what I said in the other thread, so people will see that I know what I am talking about. I pointed out in that post how it is *already* working in the reverse, running Amiga stuff unchanged and on different architecture--heck, with the Amiga OS installed on it...
http://ann.lu/comments2.cgi?view=1108556691&category=forum&start=51#message58
So, again,...YES..this can work. And the Amiga OS can be made MUCH, much faster than it currently is--and with smaller code, too.
Oh, hey, if Bernie is reading any of this, I'd be interested in knowing what he thinks about the possibility.
I'll remind everyone that anything in software can be done in hardware, and vice-versa; so expect any arguments against being able to 'bang the emulated classic hardware' to fall flat. ;-)
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 10 of 141 | Posted by Johan Rönnblom (83.248.17.174) on 19-Feb-2005 22:56:54 | Eh, I only bothered to read the first 10 slides or so, and I know
nothing about exokernels, but doesn't this seem pretty much like the
current AmigaOS except that AmigaOS doesn't have any protection at
all?
I mean, as AmigaOS calls are made by passing pointers, and OS calls
(usually) are running in the same process as the caller.. to me, the
current AmigaOS seems closer to the exokernel design, than the
"normal" kernel. Of course, without proper protection this is quite a
bit more trivial to do, but of course this also means that it's hard
to see what "AmigaOS rewritten as an exokernel" really means, as
protection is obviously one of the major concerns in exokernel design.
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 11 of 141 | Posted by Alkis Tsapanidis (Registered user) on 19-Feb-2005 23:01:55 | In Reply to Comment 9 (EyeAm):
Oh, yeah right... Do you care to explain how it will be more efficient than a system with no memory protection, no resource tracking, allowing every task to access all memory? I bet my right bollock that you can't. It's NOT more efficient than AmigaOS and noone is too scared to try anything... It's just *not worth it*. You haven't provided *ANY* scientific evidence, ANY technical evidence which prove your point. Hello? Philosophy and zodiac bullshit do not affect computer systems and their design, science does.
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 12 of 141 | Posted by Alkis Tsapanidis (Registered user) on 19-Feb-2005 23:04:42 | In Reply to Comment 10 (Johan Rönnblom):
He means that every task should have access to the whole system, including the hardware, and that the OS and hardware are cloned for each task. Ie, an application can patch any OS library but only in its own context, the state will be saved in the next context switch. This is a pipedream, saving the state of an entire OS and the underlying hardware is MADNESS!
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 13 of 141 | Posted by Alkis Tsapanidis (Registered user) on 19-Feb-2005 23:11:37 | In Reply to Comment 12 (Alkis Tsapanidis):
http://pdos.lcs.mit.edu/exo/exo-slides/sld006.htm
1) Low Level interface
Pros: Fast
Cons: Difficult to program for, expects TOO much from application programmers. This is going back 30 years in OS design principles.
2) Expose Kernel Data Structures & Hardware
Pros: Fast
Cons: EXTREMELY easy to mess up the system, *NO* matter how much protection it offers.
VERY hard to update the API as the OS as applications will rely on system internals.
According to the AmigaOS developers, this is the BIGGEST design mistake they ever did.
Now... I could very well go more in depth but I won't, unless you want me too. It's your turn to give us some evidence...
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 14 of 141 | Posted by EyeAm (68.59.54.5) on 19-Feb-2005 23:15:32 | In Reply to Comment 12 (Alkis Tsapanidis):
"He means that every task should have access to the whole system, including the hardware, and that the OS and hardware are cloned for each task. Ie, an application can patch any OS library but only in its own context, the state will be saved in the next context switch. This is a pipedream, saving the state of an entire OS and the underlying hardware is MADNESS!"
'It's all MADNESS, I say.. MADNESS,' screamed the uninformed Genesi/MorphOS supporter from the blue camp. 'Nothing they say can POSSIBLY mean anything.'
;-) Go sing something high-pitched somewhere, Alkis. You bore me. (although, I must admit, your interest in Judas Priest is about your only saving grace that I see so far).
As for the rest of you, go look at all of those slides and do your research before you decide to come and start slamming this brilliant idea after looking at only 10 slides (of 45).
Your concerns regarding memory protection are unfounded and trivial when it comes to the exokernel. You're thinking about it from the viewpoint of a microkernel, and do no see how it is arranged. But, I'm glad some have understood how close Amiga is to the design. That's what makes it so attractive for full migration to the design; it wouldn't be as hard as, say...Windows doing it.
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 17 of 141 | Posted by Alkis Tsapanidis (Registered user) on 19-Feb-2005 23:45:20 | In Reply to Comment 14 (EyeAm):
> 'It's all MADNESS, I say.. MADNESS,' screamed the uninformed Genesi/MorphOS supporter from the
> blue camp.
Hello? I'm no supporter of anyone, I'm a MorphOS/AmigaOS/MacOSX user, not anyone's lapdog.
I bore you? You haven't addressed any of the issues I said yet.
> Your concerns regarding memory protection are unfounded and trivial when it comes to the
> exokernel. You're thinking about it from the viewpoint of a microkernel, and do no see how it is
> arranged. But, I'm glad some have understood how close Amiga is to the design. That's what makes it
> so attractive for full migration to the design; it wouldn't be as hard as, say...Windows doing it.
Unfounded? Hello? You're talking about *AMIGAOS* compatibility here. Do you even know how AmigaOS works? I guess not. Dear EyeAm, unlike you, who's life consists of all kinds of superstition, philosophy and who cares what else, my life is based on scientific thinking and a keyboard. My saving grace being Judas Priest 'interest'? First of all it's no interest, it's full in depth research. Secondly, you don't know me. Anyone who does can tell you which the features of my character are. No go back into your pipedream.
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 18 of 141 | Posted by Alkis Tsapanidis (Registered user) on 19-Feb-2005 23:48:26 | In Reply to Comment 16 (EyeAm):
"A traditional microkernel passes messages through the kernel to their destination. An Exokernel doesn't deal with the message itself, it just tells the destination there is a message and leaves it to deal with it. This reduces the messaging overhead."--Nicholas Blachford (2004)
Do you know how AmigaOS tasks do it? It doesn't deal with the message or the destination. Message passing is basically done by poking directly into another task's memory. Now, of course, the exokernel approach is safer than that but it's certainly NOT faster. :-)
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 19 of 141 | Posted by EyeAm (68.59.54.5) on 20-Feb-2005 00:02:46 | In Reply to Comment 13 (Alkis Tsapanidis):
"1) Low Level interface
Pros: Fast
Cons: Difficult to program for, expects TOO much from application programmers. This is going back 30 years in OS design principles."
It isn't difficult to program for; and I should think application programmers would love to have such freedom.
Such an OS would come with default APIs and modules, which programmers could address without bother, as they always have. The more adventurous could create their own. If this is a worry, there could even be measures--software or via license agreement--to curb potential chaos and remain within some determined style guide for consistency of the over-all OS. But the thing is, the potential would be there, if/when the OS company wished to expand further.
"2) Expose Kernel Data Structures & Hardware
Pros: Fast
Cons: EXTREMELY easy to mess up the system, *NO* matter how much protection it offers.
VERY hard to update the API as the OS as applications will rely on system internals.
According to the AmigaOS developers, this is the BIGGEST design mistake they ever did."
Applications rely on them now. What's the point, or the difference? It is, in fact easier to update with the exokernel than it is with a microkernel. And if an application should require a special API, then the adventurous programmer, or the one who cannot wait, can write one for it! :)
It's almost as if each program is 'banging the hardware', because the exokernel has facilitated it directly to the apps. That's why it is faster. A lot is not having to go through the kernel and back to user space, and back and forth. A lot of that is cut out with this design.
You could even try out different taskmanagers. Surely, the OS would have its own default taskmanager; but you could even replace it if you deemed it necessary. Nothing to disturb the security of the whole OS, mind you.
In mine, I'm going with this arrangement:
Symmetric & Asymmetric Multiprocessing
SeasonScheduler with Scheduler Activations and a Progressive Multi-Level Scheduling Policy:
* Round Robin Scheduling (for Top-Level)
* Dynamic Priority-Based Scheduling (for Secondary Level)
Security & Stability are the most important things in an OS--without either, you can dare have the rest.
"Now... I could very well go more in depth but I won't, unless you want me too. It's your turn to give us some evidence..."
I've been posting evidence that you refuse to read seriously. :)
We could just agree to disagree. On my side, we have someone always pursuing lines of thought that may well lead to innovation; on your side, we seem to have someone always pursuing the line of thought an obstructionist might have.
I would say again to consider my other post, where I remarked on the reverse situation. I mean, think of Amiga Forever, and how the Amiga OS can be installed there. There is NO Amiga classic existing anywhere under that. It's a PC. Yet it runs Amiga software.
Amithlon... People killed that off, but why? ;-) Don't want to really make Amiga a success? Have your own ideas about Amiga that you'd rather implement--if so what are they, and how are they better? How are they more successful. All of this is to you, you, and the next you--from Amiga, Inc. all the way over into the so-called blue camp. You just can't get together, work together, and make any kind of success...why? Maybe because you keep shooting down the good ideas. Fear of success or something, I don't know.
What has been put in place over the last DECADE...hasn't been working, people.
The parts are there. The successful arrangement obviously has not been found by you yet. Does this burn, sting? It is the truth.
So, okay, consider exokernels. And consider the Linux drivers. Look at WINE, look at Amiga Forever and UAE, and look at the Catweasel and CrossDOS. And by all means, look at AMD64! ;-)
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 20 of 141 | Posted by Johan Rönnblom (83.248.17.174) on 20-Feb-2005 00:20:47 | In Reply to Comment 19 (EyeAm):
No, I don't see any reasons to read more.
I'm not slamming the idea of exokernels, I'm sure they make an
interesting research subject, and maybe something can come out of it.
But clearly the idea of "AmigaOS rewritten as an exokernel" is pretty
much nonsense, as the whole point of the exokernel seems to be to get
*both* minimal overhead in the OS (as AmigaOS already has) *and*
protection (which AmigaOS lacks completely). So to get one thing you
have to do nothing, to get the other thing.. well, then we're leaving
the subject of AmigaOS. You definitely can't "rewrite exec" to work
like this, we're talking about rewriting all of AmigaOS, all OS
libraries.. and probably all the apps, too.
And.. you're definitely not going to get message passing any quicker
than in AmigaOS, if you want a protected system. If you don't believe
me, make a new post when you've got a prototype up and running.
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 21 of 141 | Posted by EyeAm (68.59.54.5) on 20-Feb-2005 00:49:46 | In Reply to Comment 20 (Johan Rönnblom):
"No, I don't see any reasons to read more."
Translation: "I know it all, I don't need to read more. There can't possibly be anything that is there that I don't already know, even though I haven't read it."
You weren't the bright kid in your group, were you? ;-)
Stay there and stand in your Status-Quo spotlight, then. But don't be surprised when the lights go out. It'll just be me changing your world for the better.
"I'm not slamming the idea of exokernels,
Yes you are, yes you are. :-P
" I'm sure they make an interesting research subject, and maybe something can come out of it. But clearly the idea of "AmigaOS rewritten as an exokernel" is pretty much nonsense, as the whole point of the exokernel seems to be to get
*both* minimal overhead in the OS (as AmigaOS already has) *and*
protection (which AmigaOS lacks completely). So to get one thing you
have to do nothing, to get the other thing.. well, then we're leaving
the subject of AmigaOS."
Did you honestly believe the classic OS could survive and thrive forever, without change? I completely disbelieve that any of the original programmers would tell you today that it was meant to.
Fear change. ;-) For it surely comes.
Also, you don't expect me to believe the *PPC VERSION* of Amiga OS is the same as what we've always had, do you?
"You definitely can't "rewrite exec" to work like this, we're talking about rewriting all of AmigaOS, all OS libraries.. and probably all the apps, too."
PPC. PPC. PPC. ;-) What's the difference?
"And.. you're definitely not going to get message passing any quicker
than in AmigaOS, if you want a protected system. If you don't believe
me, make a new post when you've got a prototype up and running."
Message passing (sockets). This is somewhat a moot point, in a way. And it depends on what context you're talking about. With exokernels, a lot of stuff is removed to the user level, and a lot of communication with the kernel (exokernel vs. microkernel) is done away with. So, in effect, there is at once less messaging going on than 'normal', and cumulatively things are faster in that respect; but...what is going on at user level would certainly be no lower than 'normal'.
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 22 of 141 | Posted by Alkis Tsapanidis (Registered user) on 20-Feb-2005 01:02:21 | In Reply to Comment 21 (EyeAm):
First of all, AmigaOS is not a microkernel OS, Exec by itself isn't strictly even a Kernel. Secondly, message passing is meant in the context of IPC. Under the AmigaOS environment, you do not go through the "kernel" to do any IPC. You directly modify the SIGBITs of another task. There's no
IPC system that can be faster (and more insecure). Yes, that's how it works on OS4 and MorphOS too,
that's the AmigaOS way. Change that and you lose all compatibility with all apps. That's one of the main reasons for which everything below expansion would break if you implemented MP in AmigaOS.
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 23 of 141 | Posted by EyeAm (68.59.54.5) on 20-Feb-2005 01:06:55 | In Reply to Comment 22 (Alkis Tsapanidis):
This is the better way to move forward and *use* the past in a different way. I do not believe you can migrate *with* the past the way it is.
Rather--and this is one of the better points with going PPC, but not that I'm a defender of PPC--going with the newer architecture of PPC (versus that of the classic) allows them to emulate the things of the past machines/OS. But, again, it can be done better from an exokernel root.
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 24 of 141 | Posted by EyeAm (68.59.54.5) on 20-Feb-2005 01:12:14 | Amiga OS is a Microkernel OS. It's not Monolithic, that is for sure; and it isn't (yet) exokernel. And, yes, I know where Amiga OS came from--the kernel was written and Tim King's TripOS crowned it.
Now check this out. It's from the University of Alabama:
------------------------------------Quote:
Exokernel’s premise: “the lower the level of a primitive, the more efficiently it can be implemented”.
Exokernel goal: to separate resource protection from resource management
* How to achieve: provide kernel interface at lowest possible level, if possible, directly to the hardware.
* Resource management can be left to the application (untrusted)
* Resource protection is the function of the kernel and is applied to raw resources (e.g. a section of physical memory) rather than to an abstraction (e.g. virtual address space)
The authors claim that traditional operating system services are too general.
* Application performance is hurt because the abstractions are compromises –.
* OS abstractions hide information that applications could use to manage their own resource allocations. Database system, for example, may be forced to build its own random access files on top of the OS file system (instead of being able to interact directly with disk using raw I/O statements.
* OS abstractions limit application functionality because they are hard to change. New developments in OS research may not be incorporated into current OS’s.
How does an exokernel change this? By giving power to the application.
* End-to-end argument: Since applications know more than the OS about how their own resources should be managed, let the applications do it – and don’t make a lower level program (OS) do it too.
Applications request resources and the kernel allocates them, using some kernel-level allocation policy. Applications manage the resources as they wish.
Library operating systems are built on top of the exokernel. They run in user space and thus limit number of traps to the OS. This is a performance enhancer – fewer mode switches incurred.
* Applications interact with the library OS. They can choose one that is provided, or write their own.
Big challenge: how to keep applications from hurting each other. (We’ve studied protection in a traditional operating system; how can we extend similar protection in the exokernel model?)
* Secure binding: An exokernel is able to guard resource usage
* Visible revocation: an exokernel can reclaim resources when necessary
* Abort protocol: if necessary, it can break a secure binding if a library OS is hostile.
Design principles – “Expose” meaning not hide from upper levels
* Securely expose hardware: the kernel exports very low-level hardware resources such as privileged instructions, specific physical memory, interrupts,
* Expose allocation: Library OS is allowed to ask for specific physical resources, although it may not be granted its request (ex. adjacent file blocks)
* Expose names: Names are things like addresses, freelists, location of the disk arm
* Expose revocation: provide details under which resources are revoked, so library OS can manage the resources it has efficiently.
-------------------------------------------------------
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 25 of 141 | Posted by minator (82.123.152.244) on 20-Feb-2005 02:11:22 | In Reply to Comment 16 (EyeAm):
>"A traditional microkernel passes messages through the kernel to their destination.
>An Exokernel doesn't deal with the message itself, it just tells the destination there is a
>message and leaves it to deal with it. This reduces the messaging
>overhead."--Nicholas Blachford (2004)
So someoe *does* read my scribblings - Cool!
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 27 of 141 | Posted by Alkis Tsapanidis (Registered user) on 20-Feb-2005 02:47:19 | In Reply to Comment 24 (EyeAm):
I understand what you mean now. Allowing the application to use any level of abstraction it wants, from high level stuff down to almost hardware banging. That would be good for an embedded system for example but I still believe that in a desktop or server environment, multitasking would be seriously cripped. By having to save the state of all hardware in each context switch the latency will increase exponentially as the number of tasks increases. A full cycle could take ages!
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 28 of 141 | Posted by EyeAm (68.59.54.5) on 20-Feb-2005 02:53:15 | In Reply to Comment 26 (Alkis Tsapanidis):
"Sure, you know more about the AmigaOS than Carl Sassenrath! He was the one that claimed that AmigaOS has no Microkernel. As I already said, the exec is no kernel, strictly speaking."
He may have considered it differently; but it does not negate the fact that its classification would indeed be "Microkernel", according to common useage and definition of the <a href="http://en.wikipedia.org/wiki/Microkernel">term<a/>. Based on its components, it deserves the title.
Exec is the name that was given to the Amiga kernel.
Wikipedia even acknowledges that the Amiga OS has "a microkernel with preemptive multitasking". However, I believe it is more appropriately a microkernel with "true preemptive multi-programming". :)
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 31 of 141 | Posted by EyeAm (68.59.54.5) on 20-Feb-2005 04:17:45 | In Reply to Comment 30 (Alkis Tsapanidis):
With the GUI, device drivers, et. al. added, it was too TripOS.
Anyway, check this out, http://cdsmith.twu.net/professional/osdesign/ch01.html
Some good info on kernels, their distinctions, as well as (if you continue following the arrow keys to the following pages) schedulers, including the one Amiga OS 4 is using (Round Robin).
This is but one site that was an inspiration for my memory managing API, MemBRAIN, which includes the SeasonScheduler. "It provides Pervasive Multitasking with true Pre-emptive Multiprogramming (where necessary) through Scheduler Activations and a Progressive Multi-Level Scheduling Policy: 1) Round Robin Scheduling (for Top-Level); 2) Dynamic Priority-Based Scheduling (for Secondary Level)". Security & Stability is an issue, so it made sense for me to create a kind of dual-manager/scheduler where such an issue is always the priority of the kernel. I mean, that's what the exokernel concerns most of all: safely multiplexing the hardware to the apps. It shouldn't care about anything else; you can leave the abstraction to the user level. That's the whole idea.
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 32 of 141 | Posted by Alkis Tsapanidis (Registered user) on 20-Feb-2005 05:10:27 | In Reply to Comment 31 (EyeAm):
Intuition was written before TripOS was incorporated into the AmigaOS, solely by RJ Mical. Same about everything Exec, including devices. Now, the DOS stuff are TripOS of course, the whole high level device structure of the system is, as dos.library was essentially TripOS! :-)
About the rest, I'm gonna read them, it seems that we're getting something good out of this, me incorporating some more radical stuff in my way of thinking and you removing some unfeasible stuff from your design principles! :-)
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 33 of 141 | Posted by EyeAm (68.59.54.5) on 20-Feb-2005 05:21:20 | In Reply to Comment 32 (Alkis Tsapanidis):
"Intuition was written before TripOS was incorporated into the AmigaOS,"
I know that. And TripOS already had a circulation of over 1 million.
"solely by RJ Mical. Same about everything Exec, including devices. Now, the DOS stuff are TripOS of course, the whole high level device structure of the system is, as dos.library was essentially TripOS! :-)"
Right.
"About the rest, I'm gonna read them, it seems that we're getting something good out of this, me incorporating some more radical stuff in my way of thinking and you removing some unfeasible stuff from your design principles! :-)"
Now, here I have no idea what you're talking about. You've not offered much at all beyond 'status quo' stuff, and seem to be completely afraid to move into radical territory. I for one am not.
If you're referring to the comments about my OS, I guess you never did see my operating system webpage. ;-) I was posting old info here.
I have not altered my view whatsoever, based on anything you've said. I don't put in unfeasible design principles, ultimately, into anything I do. ;-)
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 34 of 141 | Posted by Alkis Tsapanidis (Registered user) on 20-Feb-2005 06:11:34 | In Reply to Comment 33 (EyeAm):
As a matter of fact I have read the entire page line by line but that was almost a year ago! ;-)
I'm not afraid to move into the radical area, it's just my opinion that one has to be radical where it's needed, not everywhere just because it can be done. To move AmigaOS forward you gotta get rid of the legacy, moving it, for example, into a sandbox, it's not technically feasible to provide any memory protection to AmigaOS apps. So no, I don't believe that AmigaOS should be turned into an Exokernel,
it would be more worth it to design a similar system from scratch, taking all the problems I mentioned into account and solving them at the design level, not during the implementation or anything.
For example, I believe that a hybrid system would be better as you would be able to provide both ultra low level stuff like direct hardware and OS structure access but also totally abstracted APIs. That way you don't have to assume that all tasks will access the hardware and save it's state in every context switch for example, simply because they won't. In most situations, developers will still prefer using the already available OS APIs to do stuff, simply because the speed difference won't be always that great, it really depends on the program itself.
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 35 of 141 | Posted by Chris Hodges (62.245.211.123) on 20-Feb-2005 08:17:37 | ... I've got no time to read this whole thread here, but I held a seminar speech at university about the exokernel five years ago (for german speaking people, the foils and handouts are here: http://www.platon42.de/cgi-local/navbar.pl?0000&tum.html).
And all for these five years, I've been thinking about a new OS based on the Exokernel approach, because most of the performance problems of Linux/Unix/Posix/Windows come from the silly APIs and "open" structures, that cannot be extendend in future versions for legacy reasons. POSIX is the best example of a grown API, there is no space for modern system design. There is no space for added functionality. These strict APIs are the reason you cannot do things the right way, because they hide information (due to abstraction) from the Applications, that could have taken benefit from more information. So my approach would be a black boxed Tag(List)-based API Exokernel and libraries.
For example, the file open command under unix only takes very few optional parameters. This is not state of the art. An Application knows what it will do with the file. Take these scenarios:
a) An App is opening a file as log file for writing. Given the App would tell this to the Open call as an optional taglist entry, the file system would know about it and take precautions, such as reducing fragmentation by allocating more sequential blocks (or at least "tainting" them).
b) An App wants to copy a file. Hence, it knows how large the file would be. Again, it could tell this information at the Open call. The file system would then look for an appropriate location on the HD to store it with best fit principle.
c) An App says it's going to write a large file for archiving that's not read too often. Again, this could go to a different space than are lot of small files often accessed.
Or memory handlers: malloc takes only one parameter: size. That's stupid.
a) An App creates a caching memory region for speeding up operations. It would be silly for the OS to swap this out on low memory situations. (The OS could rather inform the App that it should release some of its memory and let the App decide which page to swap out -- why? because the App *knows better*).
b) An App wants memory that will not be swapped out, because it contains decrypted data. malloc doesn't help here.
The exokernel approach is more than just a microkernel. It provides mechanisms to access resources in a safe mannor *without* losing access to the information. Anyway... just some thoughts, gotta go.
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 37 of 141 | Posted by Anonymous (80.14.246.2) on 20-Feb-2005 08:45:34 | for ( int counter=0; counter<end_of_time; counter++ )
{
try
{
string buzzword;
buzzword=EyeAm->DiscoverNewBuzzword();
EyeAm->GetHardonAbout(buzzword);
EyeAm->DemandNebulousDisorganisedGroupOfProgrammersUseItInAmigaProjects(buzzword);
if ( Audience->Reaction() == hilarity )
throw EyeAm->HissyFit( );
} catch ( ... )
{
EyeAm->RantIncoherently();
}
sleep(g_until_next_time);
}
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 39 of 141 | Posted by Don Cox (Registered user) on 20-Feb-2005 10:25:46 | In Reply to Comment 11 (Alkis Tsapanidis):
"Do you care to explain how it will be more efficient than a system with no memory protection, no resource tracking, allowing every task to access all memory?"
It seems to me that "memory protection" is a means to an end. The real aim is crash prevention. IMO the best route to that end is to make it easier to code bug-free programs. That means less coding in C and more use of higher level programs.
It would also help to have more shared libraries in the Amiga OS, so that more of the guts of a program can consist of library calls. The programmer would mainly concentrate on the GUI. For example, a spell-checker.library, an image-processing.library, an audio-processing.library. The aim being to build up a body of well-tested code. (Which can be coded in C or whatever - the important thing is very thorough debugging.)
Superview library is a good example.
The Amiga single memory space does have advantages and it seems a pity to complicate the OS just to prevent crashes
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 47 of 141 | Posted by Megol (130.240.196.54) on 20-Feb-2005 12:23:02 | In Reply to Comment 22 (Alkis Tsapanidis):
"First of all, AmigaOS is not a microkernel OS, Exec by itself isn't strictly even a Kernel."
What? Exec is a microkernel, sure you could bypass it and fiddle with the IPC yourself but that is due to the lack of memory protection and nothing else...
And to claim that Exec isn't a kernel?!?
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 48 of 141 | Posted by Megol (130.240.196.54) on 20-Feb-2005 12:36:48 | EyeAm, you are clueless. Until you understand what you are "talking" about there is no use arguing with you. The Internet is full of online tutorials and papers about operating systems and different types of kernels, try to read them and try to _understand_ them. Then you can argue.
Reply to this comment | Top |
|
[Top] [Next 50] Add comments | - Links
- Support ANN
- ANN is hosted by Dreamhost. Sign up through this link and I will get a 10% commission on any account you purchase.
|
