| [Forum] Amiga Exec kernel rewritten as exokernel | Link |
|
Amiga Exec kernel rewritten as exokernel : Comment 53 of 141 | Posted by Fabio Alemagna (Registered user) on 20-Feb-2005 14:22:58 | In Reply to Comment 52 (Don Cox):
> I think the question is, what functions are included?
>
> A library is only one convenient way of storing a collection of code for various
> functions.
Exactly, that's more or less the exokernel principle. The OS doesn't provide any specific functionality "per se", it's just a collection of user-level modules which provide some functionalities. Depending on which modules and which functionalities those modules provide, you get a different operating system each time.
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 57 of 141 | Posted by Don Cox (Registered user) on 20-Feb-2005 15:04:11 | In Reply to Comment 54 (Anonymous):
I would expect a basic kernel to include timer routines, task management and scheduling, interrupt control (which is a part of task management), and message passing functions.
It should be able to work with only a CPU, ROM and RAM. To see what it is doing, you would have to add a couple of switches and a couple of LEDs or beepers.
Functions such as keyboard or mouse control are interrupt-driven and should be interchangeable modules outside the kernel itself - but as they are used so much, it is a good idea to store the code in a ROM. Nowadays, instead of a single keyboard port and one type of mouse port, an Amiga could have a mouse on a Catweasel, a PS/2 socket, a USB network, or a serial port. No doubt there will be more in the future. They should all work at boot time.
This is why hardware support should be in modules which can be selected by the user, even if they are in a ROM - and not compiled into one enormous file called a kernel. All the above examples would generate interrupts, so in principle you could plug in several mice at once, and they should all work.
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 59 of 141 | Posted by Joe "Floid" Kanowitz (69.0.55.174) on 20-Feb-2005 15:44:26 | I'd say that, if you want an "exokernel" Amiga, you'd be better off pushing for DE on Xen or the like... and I'm actually somewhat serious about that, it'd be yet another way to get around the "Well, it's neat, but how to drag it kicking and screaming into the corporate world?" problem with it.
Xen 'perhaps' solves the issues on the one CPU, VP/DE solves the crossplatform problem, and then if you have, say, a raytracer worth porting to some ridiculous big IBM iron, you could run the DE processes directly under whatever IBM's solution is there, without taking the 'overhead' of Linux as a shim, assuming DE is 'easy' to port. (Okay, I just dragged out of bed, anyone want to tell me if the math even works out there?)
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 60 of 141 | Posted by Joe "Floid" Kanowitz (69.0.55.174) on 20-Feb-2005 16:13:58 | In Reply to Comment 58 (Anonymous):
...and with all the blathering, is there anything wrong with declaring us proud inventors of the "Amigakernel" and being done with it? In this model, you aim for lightweight 'threading' within a shared address space, shooting for microkernel-like modularity without the overhead, then, depending on the system you're building, isolate userland or not, and/or allow libraries to protrude into kernelland (exokernel-style) or not?
Doesn't that happen to create a good 'compromise' when it comes to the needs of a desktop system, hence Windows and Linux and a certain neat BSD under development cribbing from it where they can? Out in reality, the 'true exokernel' thing seems to hinge on being able to trust those libraries, so cramming all that functionality 'back' into a monolithic design can be taken as an expression of "Look, this is the only code we think works." (Which, sure, is as infuriating as Apple's one-button mouse when it doesn't, but all an exokernel buys you is that little sprinkling of OOP in terms of how library interfaces are presented -- fine if they're monolithic, tangled if they get codependent -- and the option to 'varsym' kernel functions based on what library you're linked to, right?)
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 61 of 141 | Posted by Fabio Alemagna (Registered user) on 20-Feb-2005 16:15:41 | In Reply to Comment 58 (Anonymous):
> I said it already, that is not the definition of a microkernel. stop confusing
> how they are typically implemented with the concept. the seperation and the
> modular design is the important bit.
The one confusing implementation with concepts is not me here. By your definition, Linux is a microkernel: it provides well defined interfaces and abstractions for accessing device drivers, filesystems and what not.
It's even modular, in fact you can have the so called "kernel modules".
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 63 of 141 | Posted by Fabio Alemagna (Registered user) on 20-Feb-2005 16:26:28 | In Reply to Comment 62 (Anonymous):
> There is a whole load of argument about that if you go and search usenet
> arguments. Linus himself concedes its a mix.
Clean interfaces and abstractions aren't an exclusive property of microkernels, they are simply the proper way to design any software. You can't claim a microkenel is such just because it provides an API for accessing device drivers uniformly. Unix, since the introduction of the VFS, has always done that internally, and externally it's like that since the beginning: what more of an abstraction do you want than "everything is a file"?
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 65 of 141 | Posted by Don Cox (Registered user) on 20-Feb-2005 17:18:28 | In Reply to Comment 63 (Fabio Alemagna):
"You can't claim a microkenel is such just because it provides an API for accessing device drivers uniformly. Unix, since the introduction of the VFS, has always done that internally, and externally it's like that since the beginning: what more of an abstraction do you want than "everything is a file"?"
What makes it "micro" is that it contains as little as possible to enable multitasking. The only hardware addressed is the CPU, memory chips, and a hardware timer - all of which are usually on one piece of circuit board.
Add any other hardware, such as a hard drive or a mouse, and it must generate an interrupt to get the kernel to find and run a task to support it. An interrupt-based computer like an Amiga is not unlike a live animal, which is always responding as fast as possible to unexpected external events.
"Everything is a file" is IMO a poor abstraction. It implies something like a leisurely existence doing obscure research in a library, with plenty of time for everything.
IMO a stronger abstraction would be "everything is a surprise".
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 66 of 141 | Posted by Fabio Alemagna (Registered user) on 20-Feb-2005 17:52:54 | In Reply to Comment 64 (Anonymous):
> I never said API. You did. Again you mix up implementation with concept.
You didn't say API, but you implied it. API just means Application Programming Interfaee, you can't program without an API.
Since you want to play dumb, I'll reformulate what I said: you can't say a microkernel is such just because it provides an abstraction to access devices, filesystems and whatnot.
Content?
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 73 of 141 | Posted by Joe "Floid" Kanowitz (69.0.55.174) on 20-Feb-2005 19:05:13 | In Reply to Comment 65 (Don Cox):
Don Cox said,
"Everything is a file" is IMO a poor abstraction. It implies something like a leisurely existence doing obscure research in a library, with plenty of time for everything.
IMO a stronger abstraction would be "everything is a surprise".
I happened to catch Linus's interpretation while searching the other day.
Looks like Chris has it down -- obviously the 'most beautiful' behavior is to accept the most basic, streamlined assumptions in the classic UNIX model (assuming the UNIX model is 'nearly the simplest possible way to get the functionality expected of a modern system'), but not block yourself off from being more "expressive," if that allows you to do things more elegantly.
This is, of course, how human language works, with varying specificity. Every stream of bytes is a surprise, but making them available ensures you can never be screwed over by the lack of a public interface, in a rather 'exo'-tic fashion. (It also gives you some freedom to screw things up, but forcing developers to think about, plan for, and document structures at such a basic level enforces a minimum quality of code overall.)
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 74 of 141 | Posted by EyeAm (68.59.54.5) on 20-Feb-2005 21:12:52 | In Reply to Comment 34 (Alkis Tsapanidis):
"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."
I've read those pages too, I just went and found them again for the sake of this continued pushing toward exokernel here. ;-)
Also, where have I suggested *everything* be radical? I do believe I have made comments that things be rational or reasonable.
"To move AmigaOS forward you gotta get rid of the legacy, moving it, for example, into a sandbox,"
We could actually argue over semantics here, hehe ;-) Because first you're saying you can get radical, but that it shouldn't be done everywhere, and then the next paragraph you're talking about moving *everything* legacy into a sandbox (that's not radical?). But, okay, I won't argue...we'll agree that it's 'radical where needed'.
"it's not technically feasible to provide any memory protection to AmigaOS apps."
Now, here is where I must disagree. Memory protection CAN be provided to the ENTIRE OS. On an exokernel, you cannot technically escape the fact. But here is the beautiful thing: A general security is provided, practically by default, to everything within the OS (i.e., running on it, using it), because of the nature of the OS structure (with exokernel). This means even security for apps and programs that don't even need security. It just won't necessarily be specific to them, unless they require it--unless the programmers of such apps give them the means and technical aspects for them to acquire more detailed protection. There can be a mix of protected and unprotected memory--some apps having one or the other.
I must address more specifically the reference to "AmigaOS apps" in your statement above. I take it to mean anything Classic Amiga, or even on this PPC version--basically the way things are structured now. If migration to exokernel happend, I would hazard a guess that the PPC version (as anyone knows it now) would not exist, but would in fact be rewritten so that the final 64-Bit OS could be installed on either (as in both) PPC or x86. The classic Amiga OS and apps could stay the same--because all of that presents a more unique problem or or set of considerations to work with, which wouldn't be solved by emulation per se (or even a 'sandbox'), but would in fact be solved by that abstraction layer I mentioned much earlier in these threads (and the other thread we started before this one). The resulting reality would probably not give them specific memory protection in the sense that you're saying--but would give them the protection offered by the default system. Their unprotected nature would be operating within a protected nature. Of course, there is nothing preventing 'classic' programs from being rewritten after that time to gain greater protection.
"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."
This is what I am talking about. I would pipe all current PPC efforts to the design of an exokernel-*based* OS (I never said turn the OS into a kernel, hehe). A kernel does not an OS make ;-) I am indeed talking about creating a brand new Amiga OS that is 64-Bit, has an exokernel, has a GUI as familiar as the classic, with System and Work and all that we're accustomed to in look and feel--though I believe we can achieve a greater responsiveness and speed! And this 64-Bit OS would mark the new platform. Its features would include the backward compatibility of all previous Amiga software (this isn't expanding upon what once was, from the viewpoint of building upon that 32-bit architecture, this is starting with the 64-Bit and rebuilding what was familiar from before, and bringing along the 32-bit software). While this example is laughable to me, think of the jump made from 32-Bit Windows to Windows NT.
Better yet, Commodore-128 to Amiga.
(a new Amiga OS could run everything associated from the past, under one roof so to speak--all the way back to Vic-20, haha). Of course, some of those things would require optional hardware (i.e., catridges), but anyway...that far back isn't so important to me, beyond the idea of what is possible to collect together. This would go under the PRO category as "more software" to boast about, quite frankly. It's one of the things I have thought about in the past, with regard to making a new Amiga OS more attractive to people (even the crowd who "used to play games on the Amiga or Commodore machines"). A selling point, however small.
"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."
One could argue that the Amiga system/OS already does this, and has since the 1980s. But there are two problems now: 1) the classic hardware wouldn't fly today (in the sense of sales, or appeal) and 2) 32-Bit is dying in the face of 64-Bit.
Amiga OS is already halfway there to exokernel, because of its Library OS structure.
"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."
I don't see the new Amiga OS I envision as being any kind of hybrid system. I see it as still being Amiga (though not the Classic; not 32-Bit; and with a lot of new abilities and flexibility). We agree that the default APIs or modules in the OS may be preferable for many; but unlike the current path, there will be room for expandability in this area, and the potential for new/better APIs. With the hardware exposed, the entire OS could be seen as the 'geek port' that many have wanted in a new Amiga machine. ;-)
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 77 of 141 | Posted by EyeAm (68.59.54.5) on 20-Feb-2005 21:36:47 | In Reply to Comment 48 (Megol):
"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."
Oh goodie, I can bypass the 'arguing'. ;-) That will be a first in this community (hahaha...as if).
I've been reading. Quite interesting things, too.
Thanks for your valuable input. We needed that in this thread. I don't know what we could have done without your expertise. You have offered so much to our knowledge pool, mere words are not enough to describe the contribution.
--EyeAm ;-)
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 79 of 141 | Posted by Cheers (70.180.150.78) on 21-Feb-2005 05:07:14 | In Reply to Comment 74 (EyeAm):
>>>>I don't see the new Amiga OS I envision as being any kind of hybrid system. I see it as still being Amiga (though not the Classic; not 32-Bit; and with a lot of new abilities and flexibility). We agree that the default APIs or modules in the OS may be preferable for many; but unlike the current path, there will be room for expandability in this area, and the potential for new/better APIs. With the hardware exposed, the entire OS could be seen as the 'geek port' that many have wanted in a new Amiga machine. ;-) <<<<
Well, if your serious about this, then get your ideas down on paper. Maybe something will come of it in the future.
btw; this has been one of the better chats i've seen on Ann.
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 83 of 141 | Posted by Thomas Frieden (Registered user) on 21-Feb-2005 11:03:34 | In Reply to Comment 55 (Fabio Alemagna):
> I said it already: microkernels are process-centric.
I've learned that a microkernel is the oposite of a monlolithic kernel. Microkernels have a minimal set of functionality, where the rest of the functionality is provided by loadable modules (contrary to a monolithic kernel, which has everything built in).
AFAIK (and of course I might be wrong), the term microkernel does not define any procedures, but simply the architecture.
Wikipedia makes a difference in the complexity of the services provided by the kernels: Minimal abstraction for microkernels. It doesn't really say anything about how the kernel achieves that.
Besides, most devices are tasks/processes, so even the "process based" criteria would hold.
In the end, it probably is a matter of definition, and since we lack a really conclusive definition, it can't be defined.
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 84 of 141 | Posted by Treke (62.168.95.83) on 21-Feb-2005 12:35:03 | In Reply to Comment 83 (Thomas Frieden):
@Thomahs Frieden & Fabio Alemagna
As far as I've learned, microkernel vs monolithic kernel, was a big issue and battle between designers. Because the definitions were(at that time) almost the same as you've said, with only exception: The microkernel architecture uses IPC to communicate between the loadable modules (AFAIK!)and the monolithic doesn't. Even Linux has COFF loadable modules and it's not a microkernel arch. So the architecture of the micro-kernel system allows lower coupling of the modules (gfx subsystem, filesystem, etc, ... these need not to be processes). If they are processes and when they are running in virtual address spaces, the system is more stable, at least.
So the battle and the discussion issue was: Is microkernel architecture efficient enough ?(see the famous conversation between Linus and A. Tannenbaum - architect of Amoeba. I'm on the side of Prof Tannenbaum ;-))
Answer: It is(or better: it can be). See QNX, for example. The IPC communication ,when designed well, can have neglible overhead(comparing to monolithic systems) when considering the clean-nes of the architecture, system stability, scalability, maintainability, supportability it can bring ...
My 2 cent opinion.
re
Treke
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 85 of 141 | Posted by Treke (62.168.95.83) on 21-Feb-2005 12:35:08 | In Reply to Comment 83 (Thomas Frieden):
@Thomahs Frieden & Fabio Alemagna
As far as I've learned, microkernel vs monolithic kernel, was a big issue and battle between designers. Because the definitions were(at that time) almost the same as you've said, with only exception: The microkernel architecture uses IPC to communicate between the loadable modules (AFAIK!)and the monolithic doesn't. Even Linux has COFF loadable modules and it's not a microkernel arch. So the architecture of the micro-kernel system allows lower coupling of the modules (gfx subsystem, filesystem, etc, ... these need not to be processes). If they are processes and when they are running in virtual address spaces, the system is more stable, at least.
So the battle and the discussion issue was: Is microkernel architecture efficient enough ?(see the famous conversation between Linus and A. Tannenbaum - architect of Amoeba. I'm on the side of Prof Tannenbaum ;-))
Answer: It is(or better: it can be). See QNX, for example. The IPC communication ,when designed well, can have neglible overhead(comparing to monolithic systems) when considering the clean-nes of the architecture, system stability, scalability, maintainability, supportability it can bring ...
My 2 cent opinion.
re
Treke
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 87 of 141 | Posted by Joe "Floid" Kanowitz (69.0.55.174) on 21-Feb-2005 16:00:15 | In Reply to Comment 84 (Treke):
Treke said,
As far as I've learned, microkernel vs monolithic kernel, was a big issue and battle between designers. Because the definitions were(at that time) almost the same as you've said, with only exception: The microkernel architecture uses IPC to communicate between the loadable modules (AFAIK!)and the monolithic doesn't. Even Linux has COFF loadable modules and it's not a microkernel arch. So the architecture of the micro-kernel system allows lower coupling of the modules (gfx subsystem, filesystem, etc, ... these need not to be processes). If they are processes and when they are running in virtual address spaces, the system is more stable, at least.
The other side of the coin is that 'real IPC' theoretically has more overhead than sharing memory to begin with (kernel-global variables or Amiga-style IPC).
Then we get into semantics -- the baseline functionality for a lot of these kernel-hacky sorts has been 'UNIX.' To do UNIX right (and get beyond it), you want process protection and VM. That demands sanity checks and kernel involvement in your IPC, and dang if protecting isn't generally more expensive than doing nothing. You get little monsters like Mach, and then everyone spends 20 years trying to do something right with them.
The Amiga system, as it was realized, was a "toy" in contrast to that, since it was able to ignore those concerns... of course, that 'biggest architectural mistake' was probably a good idea, since the world couldn't afford to not bang the hardware in 1985, and saddling the 256K/512K Amigas with anything approaching a full *NIX would've made them about as useful as those Soviet DEC clones. (Which is to say, probably horribly reliable for things like that NASA telemetry, but would the demoscene have been nearly as good?)
It sounds like Sassenrath had some ideas for getting 'beyond' UNIX, maybe even in an exokernelly way, but since that was never realized, we can only wonder how it might've fared within the constraints of the hardware.
So, um, anyhow, the microkernel vs. monolithic vs. exokernel debate is "computer science" -- figuring out why things work and what the logical constraints on them are. Then there's the act of "software engineering," where people take that knowledge (or ignore it) and try to figure out *how* to make it happen.
So let's think about the projects that have survived to make themselves useful. Linux went through the monolithic experiment one more time, from scratch and out in the open, letting everyone see the promise and pitfalls of that approach. Turns out that sharing an address space can encourage rapid development, and 'forces' bug-hunting to occur, not unlike on the Amiga. Turns out that it also becomes a big mess of code, so efforts to modularize it are ongoing... but that really isn't a huge surprise, because previous 'monolithic' designs had kernel modules, too.
NT tried to hie to the microkernel party line, supposedly at least, and was quickly forced to blow gaping holes through the concept to allow graphics and 'driver' data through. From this, we discover that those protections can get 'too expensive' if you want to push huge bitmaps around on the current state of hardware... on the other hand, you may not really need to tear the system quite as big a new one, if you look at how monolithic *NIX has handled the problem. (Well, how different are the two, really?)
Darwin... Well, I'm still trying to figure that one out. Is it a microkernel forced to walk and talk like an exokernel? Mach or the derivative appears to handle some things, the 'BSD subsystem' handles others, and the two are strapped together at the hip, such that maybe nobody knows what's going on.
QNX has streamlined IPC, and maybe demonstrates that you don't need to make it hard on yourself. Now that I have half a clue what I'm talking about, I'll have to dig in and see how they really deal with the 'hardware banging' and such that makes everyone else say 'screw it' and go para-monolithic. Now we're into semantics again, if all your microkernel servers run with root priveleges, are you 'microkernel enough' or not? (Or am I starting to veer off and miss the subtleties, ah well. ;))
Point being, the debate, while founded in good principle, seems to amount to "Which problem deserves tackling first?" All we really know, aside from well-founded theory, is that microkernel projects go to hell too rapidly in absence of strong management... thus the constant 'recursion through the navel' of HURD and Be, and the "Wow, gee, that's pretty nifty, what do you mean it's inordinately confusing to license this as a desktop and you'll never make concessions over paging to disk?" of QNX6.
Meanwhile, DragonFly and AmigaOS seem to be converging on similar principles from opposite sides (that's a stretch, but hang on) -- DF just wants to untangle the mess of the FreeBSD kernel, which already provides a UNIX userland; OS4 wants to take the already-clean Amiga structure and rig it up so we *have* a userland. What difference does it really make if you're talking threaded libraries or processes? There are matters of convenience, to be sure -- AmigaOS gets to be a lot more self-consistent, taking a natural progression and all -- and 'target market' -- no matter how ridiculous a comparison you want to draw, it's pretty clear Amiga will have better gaming first and DF will have better supercomputing -- but both seem to track this fairly obvious division, where 'threading' the kernel/driver space proves nice, and passing message structures by reference proves fast (both in terms of performance and development mindslices).
So, uh, back to exokernels. You want an entirely new 'subsystem?' Let's face it, your exokernel monitor will have overhead if you want security, and most of your apps will be bound to the one "LibOS" (sort of like how that big 'BSD' gumwad on Xnu is hard to ignore). In DragonFly, or perhaps even Linux, you can probably find a way to munge this in as one big kernel module, or a libc replacement, or a little of both. (Am I missing something? FreeBSD 5's threading mess sure makes it 'feel' like I'm 'changing' some basic kernel behaviors every time I rejig libmap.conf, even as the various libs do rely on the kernel structure being present to do their dirty work, and the mutex mess arguably makes goofing with that behavior harder than it needs to be...) In AmigaOS, it probably is a little more straightforward -- push something new under Exec, maybe call it an 'accellerated application-specific http driver' instead of a LibOS -- and you've still got the same feature as in the exokernel example, right? Heck, you don't even need to tear down a big mess of a kernel to work this way -- you just add the features of the exo project's "DPF" to get around the fact that your existing code path sucks! (Hmm, now in BSD-land, does Netgraph provide the hooks for that already? Anyone want to rewrite Apache from scratch and find out?)
The exokernel 'perspective' reminds you not to screw third parties out of control at that low level... The question is whether anyone should bother diving down the refactoring rabbit hole ("Waah, waah! Must have new buzzword! Delay next release another twelve years!"), when 'we' have the advantage of generally knowing how not to be stupid and blundering into functionality when the time is ripe. ;) More seriously, this whole exercise can be taken as headsup not to wall off that possibility, while going straight exokernel would sort of just give us MorphOS, right? ("Ooh, look, it does all this... to run the Amiga compatibility layer... with few protections... and we've just come full circle... Oh, hell, let's cause a flap about widget-library exclusivity!")
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 88 of 141 | Posted by Joe "Floid" Kanowitz (69.0.55.174) on 21-Feb-2005 16:31:58 | In Reply to Comment 82 (Don Cox):
Don Cox quoted,
"The "exokernel" separates resource management from resource protection."
What do you mean by "resource" in this sentence? That word is too vague to be useful.
The theory is that the exokernel just plays watchdog to everything going on under it. If you come up with a fairly smart and elegant way to do it, as those MIT guys might've in some cases, you get a new API (like the 'filtering' network multiplexer, that just concerns itself with serializing everything coming out of the LibOSes into a less-schizophrenic representation on the wire) that lets your 'kernel' be hands-off, and thus more abstract, more elegant, whatever.
In practice, creating a meta-system to allow "arm-wrestling contests" (scheduling, hardware or data contention) without actually knowing about arms or wrestling is as wacky as it sounds, but they did their reference implementation to show it can be done, and even perform well.
A big, big question is whether it's worth putting in the effort to discover the exact magic sauce from scratch, when they put in the grunt work to sort out all the side-effects. Once you have a good 'exokernel,' hey, sure, bang together an Amiga LibOS under it or something (or 'port' it, since a good exokernel looks a lot like Xen, and like Xen, is likely to reside out of the way of your branding), but it'd be sort of cool to sort out what one userland (the "new Amiga" one) looks like before we get into all these application-specific, um, "Q-Box"es. (Of course, the exokernel approach may be the best way to bring together 'gaming' and 'serving' on one system, considering it gets more expensive to deal with latency vs. throughput fairness the further you get from the hardware. If I didn't just make that up.)
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 89 of 141 | Posted by EyeAm (68.59.54.5) on 21-Feb-2005 20:54:25 | In Reply to Comment 82 (Don Cox):
"What do you mean by "resource" in this sentence? That word is too vague to be useful."
Hmm. That's pretty much the definition, or difference shown, between microkernel and exokernel. But I suppose one could take out the word 'resource' there and it would still sufficiently describe the exokernel: separating management from protection. Or, even more specific, separating management (of resources) to user level from protection (of same resources) at kernel level.
The claimed advantages:
* Speed (smaller kernel overhead, faster booting..)
* Flexibility (abstractions left to the apps; hardware more exposed to apps)
* Security (kernel's main job is safely multiplexing hardware to user level;
at which point APIs, modules, apps may provide even more security)
* Stability (I dare say a system can be built that will not crash, outside of
something happening to the hardware--it comes down to the apps
and the programmers of those particular apps, as to how stable
those will be. Rather, it will quickly be seen who writes the
better or more stable programs. And they won't bring down the
system or cause a system crash).
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 90 of 141 | Posted by EyeAm (68.59.54.5) on 21-Feb-2005 21:25:22 | In Reply to Comment 83 (Thomas Frieden):
I think the distinctions concern what resource control is rooted in the kernel (i.e., *where* the resource control is vested), and the abstraction of that control.
It would be far easier to install/write a driver on the OS with an underlying exokernel and put it into the path where it could be found by the OS--to run an additional hardware components (say, like a new mouse or somethign)--and have it run immediately...than it would be on a monolithic kernel based OS. The intermediate range where the microkernel is found, might well be a toss-up as to whether the same kind of thing could be done. Or to change an existing driver. And without rebooting.
In my view, the monolithic kernel holds quite a number of reigns on resources and hardware when everything boots up. If you want to change anything, you have to download into the kernel (if it's even set up to let you do that). There are numerous calls to and from the kernel, and this is where the overhead is higher compared to other forms of kernels.
In the microkernel, the number of reigns on resources may be spread a little to the user level and libraries; but still with considerable control vested in the kernel. Compared to the monlithic kernel, the microkernel would be less 'locked-down'.
In the exokernel, its only concern seems to be security for the whole of the OS and machine(s) it works with, booting up quickly due to the lower overhead and required calls. It pretty much sets up a stable environment and lets the app go from there, managing themselves the way they need/know to. Compareed to the microkernel, all control of management of apps and other resources would given up to the user level. Apps would address default API modules or their own APIs (for their own plug-ins, etc.). I think realistically there would be a module there, too, for further security and protection.
Perhaps an analogy can be made to the Amiga Workbench and how there was MUI and (I never can remember the other one, because I didn't use it), but more than one program that handled the changes in the look of windows and scrollbars, and globally doing so. In similar fashion, there could be default APIs and modules on an exokernel-based Amiga OS, as well as others that did the same/similar/better/worse thing for other apps.
If it sounds like the Amiga could suddenly become almost anything (limited by what an OS can be, of course), it feasibly could. This is where the earlier reference rested concerning how most programmers would probably just use the default APIs. The expandability would be there--and isn't it great that someone might come up with something new and innovative? The company might like that new API and contract with the programmer to include it in the next version of Amiga OS. All along, the OS could evolve and get much better. In a way, it could almost be like Amiga's own 'linux' community, because of the way the new things could be tried out and be adapted. (this is practically how you can have a proprietary OS with Open-Source modules--well, for the modules released as such) :)
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 96 of 141 | Posted by Joe "Floid" Kanowitz (69.0.55.174) on 22-Feb-2005 03:20:26 | In Reply to Comment 94 (EyeAm):
Here's an interesting article about adapting MAC OS X to an exokernel. Mentions QNX, too...
http://www.apple-x.net/modules.php?op=modload&name=News&file=article&sid=951
I could be wrong about this, it could be only the system management tools that 'suck' this badly, but a whole *whonk* of OS X is beholden to the "BSD subsystem" for its general function, and (I'm assuming) at a level intermingled enough to make portability off it less than an ecstatic proposition.
Ergo, OS X probably isn't a "good" candidate for moving to an exokernel beyond the fact that they've tangled up monolithic BSD and Mach, so why not the kitchen sink, too? And forcing people to rewrite everything one more time is the Apple way, it ensures those iApps will always be 'ahead.' (Doesn't it feel like the fruity camp are reliving Windows' successes, c. 98SE, but with a userbase that actually likes to drink the Kool-Aid?)
I mean, not really that bad, they could always reimplement those APIs in the exact same fashion of the exokernel group and reap the little benefits, but it seems like the way the average Mac developer targets userland is already a real-world example of LibOS dependency hell. (Maybe I'm just bitter, and extrapolating from my attempts to configure the system and finding neither BSD nor NeXT semantics fully apply.)
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 97 of 141 | Posted by EyeAm (68.59.54.5) on 22-Feb-2005 03:38:12 | In Reply to Comment 95 (Alkis Tsapanidis):
Define your 'sandbox', because if you're talking about having to go into something like Amiga Forever--on an Amiga OS system--then I would suggest forgetting that entirely. Why emulate what you own? The old, 32-bit stuff can reside adjacent to the newer 64-bit stuff. It would be my hope that the 'sandbox' discussed over the last few years could be quite invisible, and that no one would really have to go into some other screen or mode just to get to an programs that is running on another OS. I'm less opposed to having a classic OS being installable on the new one, but let's try to keep the extra hoops down to a minimum.
An exokernel-based Amiga OS could treat the classic OSes as 'programs', IF one had to go that way. But I recall a time when I had my A2000HD and there in the System libraries sat drivers for an '030 card and an '040 card, and whatever else I was using. Such things aren't called up unless they are needed; but the point being, the classic 32-bit stuff can sit right next to the new stuff, and the new OS can have the same structure we're all familiar with, as far as where things go (C drawer, Libs, etc.). The difference being, it's 64-Bit, and there are things no longer going through the kernel, making calls to and from that; and the classic stuff may be making calls to something at user level which facilitates the tricking of either the classic OS or the programs that might run on it...into thinking nothing is different.
All of this is absolutely possible.
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 98 of 141 | Posted by EyeAm (68.59.54.5) on 22-Feb-2005 03:47:12 | In Reply to Comment 96 (Joe "Floid" Kanowitz):
Well, they may well have greater problems than Amiga OS would. But I also do not think that their utilization of Linux drivers is far away. I don't know, maybe they already use some now, I haven't that closely. For some reason, I always consider Apple as 'just being over there'. :) But if they haven't yet thought of the drivers, they will. Steve Jobs has already thought of migrating MAC OS to AMD64 (oh yes, it's not dead).
I think the most interesting paragraph in the article is this one:
"An exokernel, however, hands off control to an application if it needs it, and doesn't give power to processes that shouldn't have it. If all elements of the system that normally slow operations down, like virtual memory, and the filesystem, are stored as application libraries, then programs can access them directly without bothering the kernel with otherwise unnecessary system calls. Thus, instead of assuming that every and all requests need to be processed through every level of the system's hierarchy, an application can opt to use the most efficient route."
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 99 of 141 | Posted by EyeAm (68.59.54.5) on 22-Feb-2005 04:38:22 | This might have been overlooked by some, so I thought I would mention again that we're not just talking about an exokernel on 32-Bit going eight to ten times what other OSes with 'lesser' :) kernels go, we're talking about an exokernal on 64-Bit.
This from the SuSE Linux site:
"The maximum memory-addressing capability (utilization of main memory) of current 32-bit processors is about 4 GB. In contrast, 64-bit processors enable a physical memory of up to 1 TB and a virtual memory address space of 512 TB. Thus, 64-bit systems incorporate computing technologies that cannot be deployed on conventional PCs due to excessive computing time. Moreover, 64-bit computers have larger caches and a more efficient memory access, which further increases the system speed. For example, a computer with an AMD Athlon 64 processor with 1.8 GHz is faster than a 32-bit computer with a Pentium(tm) 4 processor with 3.2 GHz."
Times 10 comparison (application performance results, exokernel vs. non-exokernel), then factor in the 64-Bit. If you thought Amithlon was fast at ten times the speed of the fastest Amiga, imagine it on the same PC with an exokernel, then imagine it on 64-Bit hardware. And then, of course, optimization can increase the speed/responsiveness more in some cases.
32-Bit exokernel:
"Unaltered apps run up to 4x better
"Global performance up to 4x better
"Custom applications up to 8x better"--MIT
--EyeAm
"IPC primitives coexist in the same library OS; very fast
communication between processes since no trip to the kernel code is
necessary"
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
[Previous 50] [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.
|
