| [Forum] Amiga Exec kernel rewritten as exokernel | Link |
|
Amiga Exec kernel rewritten as exokernel : Comment 101 of 141 | Posted by EyeAm (68.59.54.5) on 22-Feb-2005 06:46:38 | I jotted down some more notes in an effort to make the vision I have clearer. This is pretty much toward my dream Amiga OS. And from reading posts by Amigans over the last few years, I know others share some of these things in their idea of an OS they would like to see. So I will paste the notes below:
THE NEW 64-BIT AMIGA OS:
------------------------
Key Features & Selling Points:
* Exec64 / Exoc (exokernel) -- 32-Bit Exec rewritten as new 64-Bit exokernel
* Auto-senses your hardware, installs appropriate PPC- or AMD64- *OPTIMIZED*
Versions of the new Amiga OS.
* Real-Time Operating System (RTOS)
* Same Workbench and System structure by appearance. Same familiar GUI, but
with greater responsiveness.
* Over 80 to 160 times faster than the fastest Amiga Classic machine.
* Over 8 to 16 times faster than Microsoft Windows, Linux, or MAC OS.
* Full backward-compatability with all Amiga Classic software (every version,
back to 1980s).
* Over 150,000 software Amiga Classic titles available from the word Go.
(AmiNet, etc.)
* Full gamut of compilers, programming languages,..
* Supports up to 1TB of physical memory.
* Full Memory Protection (global/general) with further selectable memory
options for apps
* Virtual Memory (up to 512TB of virtual memory address space)
* High Security with further selectable security options for apps and ports
* Default Firewall and Port Manager (software)
* Symmetric & Asymmetric Multiprocessing
* Pervasive Multitasking with true Pre-emptive Multiprogramming (where
necessary)
* Multiple Filesystem Support, within the native 64-Bit journaling file system.
* Can utilize Linux drivers (and Linux/software) to run nearly every PCI/AGP
card on the planet
* Can run WINE (i.e., Windows programs without Windows!)
* Can scale down to PDAs, Set-Top Boxes, PC/Web Tablets (AmigaDE!)
* Can scale up to full enterprise situations and servers, and handle extreme
loads.
* Supports as much or as little Abstraction for applications desired by
programmers (i.e., can 'bang the hardware' without having to be rewritten
at next version of OS).
* Default Amiga APIs and modules with support for Open Source APIs and modules.
* Supports latest industry standards; SATA, USB, Firewire, DDR, memory sticks...
* Boots in 5 seconds or less (Instant-On)
* Can read/write common PC formats (CrossDOS)
* Can read/write Amiga Classic formats via PC disks (Catweasel technology) or
Amiga disks.
* Includes Carl Sassenrath's REBOL Messaging Language
* etc. etc.
How To Approach Obtaining The New 64-Bit Amiga OS
-------------------------------------------------
1. Rewrite the 32-Bit Exec (micro)kernel as new 64-Bit exokernel
(Exec64 or Exoc).
2. Finish PPC port, with changes to accomodate the exokernel, but consider
all of this to be the PPC-*OPTIMIZED* Version.
3. Embed and optimize AmigaDE software--doesn't matter if it's 32-Bit or
64-Bit. It makes some sense that it is probably 32-Bit, to run on the
PDAS and smaller devices outside of this OS. It might require refashioning
for the same exokernel.
4. Add whatever capability is necessary to utilize Linux drivers.
(System/Drivers/Linux/) The drivers are so attractive because they
already address what Amiga will need; and it makes more sense to write
in this capability once, rather than having to write hundreds or
thousands of drivers. The exokernel can allow for things to run unchanged;
but of course there can also be drivers with optimizations for this new
OS (PPC and x86-64).
5. Immediately after the PPC port is finished, or even as parts of it
(that take the exokernel into account) are completed, port to x86-64
(i.e., AMD64) but consider all of this to be the AMD64-*OPTIMIZED*
Version.
6. Turn Amithlon into the API/module that Classic Amiga software will
address first, enabling the backward compatability (and at fast speeds).
Probably optimized versions for both PPC and x86-64 (AMD64). Amithlon
emulates the classic Amiga chipsets and uses UAE.
(could use Datatypes in new OS?)
7. Unite all of this into one package that promises to auto-sense the
hardware and install the appropriate optimized versions.
--------------------------------------
That's pretty much it for now. :)
--EyeAm
http://s87767106.onlinehomel.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 102 of 141 | Posted by Joe "Floid" Kanowitz (69.0.55.174) on 22-Feb-2005 07:07:54 | In Reply to Comment 98 (EyeAm):
EyeAm said,
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).
Enh, it's getting late, and thus we're slipping back into the realm of direct factual incorrectness. Darwin absorbs some driver code from BSD, but perhaps not even that much; Apple has a vested interest in running a tight ship, they have a completely different model for native drivers, and this situation suits them just fine. A vendor swearing fealty is likely to be kept too busy and distracted to consider other fruit -- plus they seem to think they can trust vendors to supply working code, as the Oxford debacle proved out.
They could add Linux driver support, they could probably wrap Linux driver support, but they have absolutely no reason to -- Linux doesn't have drivers on par with vendor-provided code, especially for things that are currently causing headaches (802.11 chipsets and GPUs being particular points), and Apple likes being able to pull out the 'okay, fine, be that way, you'll lose access to our N% of the market' stick. I've suspicion a fair number of things come 'free' from BSD-land -- the FAT support, probably a bunch of the USB stack, though I haven't looked to confirm or disprove that -- but even there, that's a one way street; where BSD and Linux contain the same code, they do so because the copyright holder went BSD to begin with, or granted permission under an "Oh, crap, I didn't realize I was screwing you guys, here, take it" dual-license arrangement. You can push the GPL-with-Other combination problem back on the user, but show me where this wealth of stable binary .kos are hiding, first.
As to "Marklar," I'm sure there are people schlepping Darwin to AMD64, and I'm sure Jobs likes the thought of keeping it an option (if only to be able to offer it as a server product, and I hate to say it, but most of those big corporate clients for shiny Xserves end up using them like Slackware boxes with a prettier Webmin*), but the last thing Apple wants is a wide array of hardware support, anyway... They're plenty happy building in chipset support system-by-system, because that lessens the risk of it running on something other than what they can sell you. Once you've added, say, nForce support to Darwin (which is probably more a matter of firing up Xcode than porting from somewhere else), all the rest of the OS X magic just involves recompiling the proprietary DisplayServer and such -- they may've made the architecture a bit confusingly *ugly* from a user's perspective ("Okay, here's a Cocoa app with an odd dependency on Carbon lib that ends up calling dd and rm -rf directly with assumptions about hardcoded paths and no safety for spaces in them."**), but it's certainly *portable* in, say, the NetBSD 'didn't actively paint ourselves into a corner against it' sense.
---
Now, maybe I feel responsible for clearing this up, because way, way, way back when I advocated "Hey, screw it, a compiled Linux is negligably small now, and if U-Boot is unlikely to support bootstrap from every weird@$$ SCSI controller or Firewire disk or netboot over the 802.11 chipset of the week, maybe making Linux the second-level loader would spare development time for something more important." It since turns out that Linux was barred from working properly on good ol' Articia without an extensive refactor, the custom "SLB" was put out there for some other reasons anyway, and when the time is ripe, that can probably be replaced with some sort of mini-AmigaOS image using native drivers to get you from "U-Boot doesn't know about this particular weird class of device my boot volume is on, but AmigaOS does, so I crammed an 8MB CF on the IDE chain to be able to netboot" to a loaded and purring system. If this is supposed to derive from that in any way, I was just talking about *booting,* and even an exokernel alone ain't gonna help you in the more general case. (Got a driver for an existing Linux LibOS? Great. How you gonna access that from the Amiga LibOS? Well, at least you can bodge the hack together without rebooting, but whoops, you've got *two* OSes of overhead to plow through. I'm just teasing, but if the first thing you'd use an exokernel for is to go to dependency heck... ;))
---
*A very informal survey suggests they're at all popular for the same reason that G5 supercomputer was -- 'hey, it costed out cheap, we needed an Altivec farm for something.' I've yet to run into someone with a clue about tweaking the icons on a mountpoint under 10, let alone doing anything real with the OS-specific features; luckily Pixar and the scientific market don't really need that, as long as you can cram data in one end and suck it out the other, usually with conventional userland daemons that might be portable to straight NetBSD or were developed on Linux in the first place.
**Okay, I made that up.
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 103 of 141 | Posted by Joe "Floid" Kanowitz (69.0.55.174) on 22-Feb-2005 07:42:18 | In Reply to Comment 101 (EyeAm):
Lest I leave things on a sour note...
1. Rewrite the 32-Bit Exec (micro)kernel as new 64-Bit exokernel
(Exec64 or Exoc).
2. Finish PPC port, with changes to accomodate the exokernel, but consider
all of this to be the PPC-*OPTIMIZED* Version.
3. Embed and optimize AmigaDE software--doesn't matter if it's 32-Bit or
64-Bit. It makes some sense that it is probably 32-Bit, to run on the
PDAS and smaller devices outside of this OS. It might require refashioning
for the same exokernel.
Considering where things are at now, this compacts to "Write future versions of 4 bearing in mind that you might want to bung all this together as an exokernel LibOS someday." Which is what you said in the first place, and makes sense... though the hard part isn't being the LibOS, the hard part is providing the exokernel. (You willing to buy my 'if we squint at Exec really hard over time and really really believe, it'll naturally progress into the closest approximation of one worth doing' argument?)
What's this obsession over 'bitness?' ;)
4. Add whatever capability is necessary to utilize Linux drivers.
(System/Drivers/Linux/) The drivers are so attractive because they
already address what Amiga will need; and it makes more sense to write
in this capability once, rather than having to write hundreds or
thousands of drivers. The exokernel can allow for things to run unchanged;
but of course there can also be drivers with optimizations for this new
OS (PPC and x86-64).
Worse-is-better theory runs against this too, barring practical considerations. The 'correct' approach is, supposedly, to have some nards, trust in your driver model, and (these days) plug into those necessities over the network or through a 'we didn't tell you it's an exokernel so it's okay' monitor like Xen while whining really loudly until the world notices or you die trying. Otherwise, you'll never have better drivers than Linux anyway, and you might as well be running UAE on Linux (or more specifically, an ABIulator like WINE, once that becomes remotely plausible).
Thing is, Linux *is* brain-damaged in some cases (and BSD in others, BIND is a BSD project after all)... and presence of a solution doesn't preclude a native implementation, but tell that to an ex-OS/2 user. ;)
5. Immediately after the PPC port is finished, or even as parts of it
(that take the exokernel into account) are completed, port to x86-64
(i.e., AMD64) but consider all of this to be the AMD64-*OPTIMIZED*
Version.
Then create that darn yet-another-CPU problem, unless everyone's using DE (maybe they should be)...
Did I already mention that spearing 'native' DE onto Xen or something else exo- would be cool, and at least wouldn't hurt anyone out in the land of the living?
6. Turn Amithlon into the API/module that Classic Amiga software will
address first, enabling the backward compatability (and at fast speeds).
Probably optimized versions for both PPC and x86-64 (AMD64). Amithlon
emulates the classic Amiga chipsets and uses UAE.
(could use Datatypes in new OS?)
Which requires locking Meyer and Frank in Thunderdome with McEwen until...
7. Unite all of this into one package that promises to auto-sense the
hardware and install the appropriate optimized versions.
Fine by me, except supporting two CPU arches with a normal OS will always give you the marketing and support and which-hardware-do-I-need-for-what-again headaches (for a commercial operation, where this sort of thing arguably matters). I guess they could lock down OS4 and only release 'approved' apps that port across there, too... ;)
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 106 of 141 | Posted by EyeAm (68.59.54.5) on 22-Feb-2005 09:32:00 | I think it has now been more than hinted at (by some in the Amiga community) that Amiga may wind up somehow utilizing XEN. I mean, the connections are there, with IBM, which has seen some relations with Amiga in the recent past (i.e., developerworks; PPC..). But if this is the case, I think it is a mistake, compared to the exokernel route.
I looked over a few articles about XEN just a little while ago.
http://www.linux-mag.com/2004-10/xen_01.html
http://news.com.com/Xen+lures+big-name+endorsements/2100-7344_3-5581484.html?tag=nefd.top
It seems that it is just basically shoving a software shim under the monolithic/microkerenel-esque Linux, in an effort to give rise to some virtualization enough to run multiple OSes on the same hardware. One of the pages above points out 3 crucial problems with purely virtualizing the x86 hardware (page tables, privileged instructions, and I/O devices) that just are not found with doing it the exokernel way. One of the things I noticed right away concerned the privileged instructions:
From the website (about XEN):
"Certain instructions on x86 (pushf, for instance) only result in a trap when run in supervisor mode (CPU ring zero, where the operating system normally lives). However, when virtualized, the operating systems no longer runs at the appropriate level, and these instructions no longer result in traps. In full virtualization this is commonly addressed with a technique called code scanning: the virtual machine manager examines the executing binary and redirects these calls. But since this run-time scanning can be very expensive, Xen does it beforehand. One of the tasks involved in porting an OS to Xen is to replace privileged instructions with the appropriate calls."
From this page on new models for operating systems:
"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."
Now, I believe if Amiga intends on using XEN in anyway, it may be a mistake, compared to going directly toward the exokernel path. This is kind of where I sense XEN will push Linux, but I bet it will not be nearly as fast as what Amiga on an exokernel can be. And I think they're going to have more problems compared to the exokernel--not the least of which is the I/O access (i.e, in XEN, although their 'paravirtualization' is a nifty workaround, it doesn't beat direct access to the I/O by the application that needs it.)
Additionally, there is another similarity between XEN and an exokernel-based OS: "Xen is a minimally invasive manager that shares physical resources (such as memory, CPU, network, and disks) among a set of operating systems. Effectively, Xen is transparent, as each operating system believes it has full control of its own physical machine. In fact, each operating system can be managed completely independent of one another." The exokernel-based OS can do the same thing, but in a way that is arguably less like a hack.
Now, XEN at the user level of an exokernel-based Amiga is possible, in relation to running the Amiga Classic OSes/programs (and it may be fairly redundant to what the exokernel can do, anyway). SuSE is going to use XEN in probably their 9.3 version, and have User-Mode Linux (UML) work with it.
XEN also seems more tailored for multiple VMs/OSes (i.e., Linux, NetBSD, Windows...) than it is concerned with bringing the hardware directly to the apps. The exokernel-based OS, again, is capable of all of this.
XEN vs. exokernel route:
* OSes on both can be optimized.
* OSes on both achieve high speed.
* Multiple OSes can exist on either.
* With both there is scaleability.
* With both, application compatability very high.
* XEN requires OSes to be ported to its architecture (since it seems to be a little different from x86); and, although an Amiga OS would find the closest correlation in the rewriting of its kernel so that apps address something at user level (in an exposed System module), I still see this as a different case; not quite the same thing.
* Another XEN con is "relatively large amount of codelines to patch linux kernels, but mostly in the architecture dependent code"; whereas the Amiga OS would be having its kernel rewritten, so that things at user level (like unchanged linux drivers) could get at the hardware--even if they had to go through a module also at user level.
* XEN con: "currently has less resource sharing/saver features like UML"
XEN only handles up to 64 GB of RAM (if I've read this correctly). An exokernel-based Amiga OS could address up to 1Terabyte of physical RAM; and an additional 512GB of virtual memory. Now, this might not mean much, depending on how they have slid XEN in under Linux--SuSE supports up to 1TB, etc., so perhaps there's nothing to this--I might have misinterpreted what was meant by this.
XEN is not open source. Amiga would have to license it. Amiga could write its exokernel cheaper.
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 114 of 141 | Posted by EyeAm (68.59.54.5) on 22-Feb-2005 19:24:38 | In Reply to Comment 111 (Don Cox):
I did not. And it should be quite obvious what 'resources' are, Don. ;-)
I've seen your posts over the last few years, and they seem to be well-informed. Surely I don't need to tell you further that the resources in this context are those *NOT* managed by the *exokernel*, compared to those which *ARE* managed by microkernels and definitely monolithic kernels.
I spoke specifically and previously in this thread about the reigns that a kernel has versus where those end up with an exokernel. At the end of these reigns aren't horses, you know :) They are the resources which we speak of.
If it's still not clear, I recommend some of the tutorials online regarding how to build an operating system, etc.
--EyeAm
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 115 of 141 | Posted by EyeAm (68.59.54.5) on 22-Feb-2005 19:34:47 | In Reply to Comment 112 (Alkis Tsapanidis):
(digs in the Inter-Process Communication bag)
"In comparison the L4 and Exokernel IPCs are a generous order of magnitude faster, due to their clean-slate implementations. These kernels are able to do RPC calls every 400th instruction with only 10% degradation in speed, which should be fine-grained enough for almost all applications."
--EyeAm :)
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 118 of 141 | Posted by EyeAm (68.59.54.5) on 22-Feb-2005 22:40:24 | In Reply to Comment 117 (Cheers):
Eh, I posted it for greater insight into how I see things proceeding from an exokernel-based Amiga OS. :)
Hey, if you're interested in a funny little side story relating to the exokernel, Carl Sassenrath, and here, check out my latest blog entry: http://s87767106.onlinehome.us/EyeBlog.html. The Symbiotic Coincidence of Serendipitous Meaning...OR How My Path Led Me To The Intuition That Needed It
Back to the business plan thing, I don't think Amiga can really move forward without having one or considering it. I think when the times comes to create, you wear the Creativity hat, and without concern for money. When the times comes for selling or marketing, you wear the Business hat and milk it (what was created) for all its worth. When kicking around the concepts and trying to decide what is feasible and not, you alternate quite a bit to keep the perspectives balanced.
As for me, regarding the Amiga OS, I always envisioned what it would be like to sit down and work with the concept in question. From the end-user perspective. Maybe it's akin to backward engineering, or more just fleshing out the goal and focusing on that. If one doesn't know where he is headed, he will wind up anywhere. I believe things fall apart among groups if there is not a common goal in mind. Decide where you want to go and get there. Just do it. ;-) Make it fun. HAVE some fun. Be creative. Experiment. Try new things. Get a little wacky. Also consider how some of it will play in the marketplace (if you're doing something for business), and maximize the potential profit. Increase your mojo. Accentuate the positive.
That list truly contains a lot of things I would like to see, a lot of things that are valid selling points, and are quite advantageous.
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 121 of 141 | Posted by Olegil (193.212.161.66) on 23-Feb-2005 10:35:14 | In Reply to Comment 114 (EyeAm):
It's pretty clear to both me and Don that you're just throwing buzzwords out and when we're asking for a clearer definition you're unable to give one so you just mouth off about our lack of knowledge instead.
Which do you want to track? The available resources are CPU usage, memory allocation, IO ports, files opened/locked and probably a couple of others I have forgotten right now (and of course horses, coal, iron, rubber, oil, aluminium, uranium plus the seven or eight existing luxuries :-P )
There are OSes out there that to fairness algoritms on IO (for instance ethernet or harddrive access) as well as CPU and memory usage.
And now for something completely different. Namely lunch.
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 126 of 141 | Posted by EyeAm (68.59.54.5) on 23-Feb-2005 21:15:48 | In Reply to Comment 121 (Olegil):
"It's pretty clear to both me and Don that you're just throwing buzzwords out and when we're asking for a clearer definition you're unable to give one so you just mouth off about our lack of knowledge instead."
It is only proper to use the terminology associated with the concepts of which I speak.
It is baffling to me that I should have to condescend to the level of a two-year old, just so people I thought who knew more than me about programming could understand what is wholly understood by myself. Perhaps I was wrong in assessing the level of expertise of others, compared to myself.
I suggest you do the research like I have. I DO understand what is going on with an exokernel versus that of others. I researched them all. If you don't understand it, go research and then come back to the discussion. We don't need to completely complicate the thread with unnecessary, and often tedious, minutae, shen some simple concepts and the philosophy of it must be discussed first. I'll leave the rest to the instance for when it is decided Amiga goes this direction.
"Which do you want to track? The available resources are CPU usage, memory allocation, IO ports, files opened/locked and probably a couple of others I have forgotten right now (and of course horses, coal, iron, rubber, oil, aluminium, uranium plus the seven or eight existing luxuries :-P )"
And they say there are no stupid questions. :) I want the new Amiga OS to track them all, of course. (except for the latter--I think you're talking about some game there; one I don't play).
"There are OSes out there that to fairness algoritms on IO (for instance ethernet or harddrive access) as well as CPU and memory usage."
Good to know (but the sentence makes no sense, really).
"And now for something completely different. Namely lunch."
Hope you enjoyed your lunch. Thank you as always for offering that which we so desperately were looking for: levity. ;-)
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 131 of 141 | Posted by EyeAm (68.59.54.5) on 24-Feb-2005 00:42:22 | In Reply to Comment 82 (Don Cox):
>In Reply to Comment 78 (EyeAm):
>>"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 allocation and deallocation of hardware resources. The underlying physical resources that any OS has access to and uses in the sense of 'managing' and 'protecting'.
The CPU, the I/O, the PCI bus, the AGP, the memory, the harddrive, the USB, memory cards, cameras--everything on the motherboard or connected to it.
When monolithic kernels boot up, they have a stranglehold on these things, and programs and apps have to go through the kernel to use them. When microkernels boot up, they too have a strangelhold on these things, and programs and apps have to go through the kernel to use them. When exokernels boot up, they only care that the programs and apps--all of which do NOT have to go through the kernel--do so safely, in a way that whill not crash the system, will not harm other apps and programs.
"The sole function of an exokernel is to allocate, deallocate and multiplex physical resources in a secure way."--Lampson's Hints
A new Amiga OS doesn't have to give up the abstraction it has--it just needs to move it to user space and change how the calls are made so they aren't going through the kernel anymore. Amiga can, in general, keep the same API or System model, provide new ones, call what they have the default, and allow for others to create their own--for their own apps/programs, or for the entire system if they think they can do better ones. That's where Amiga OS can be opened up a bit to allow for greater expansion possibilities.
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 133 of 141 | Posted by Sammy Nordström (131.116.254.199) on 25-Feb-2005 13:19:09 | In Reply to Comment 131 (EyeAm):
For me, one of the most important features about an OS is that it abstracts the hardware from the user as well as software developer without restricting accessibility and control. This is impossible without giving the OS itself full accessibility and control of the hardware. If there would be anything that the OS couldn't do that an application banging directly on the hardware could, then it's a flaw on the behalf of the OS rather than a feature on the behalf of the application, IMO.
The exokernel idea has been around for quite some time now and I do believe there is a reason for why noone still hasn't managed to create a successful OS alternative using this kind of kernel design and why none of the mainstream OS alternatives still hasn't even as much as considered to implement it. Atleast noone that I've heard of has, the closest thing being the AmigaOS which has a flaw much like an exokernel that lets applications bang the hardware directly. So, if it would have been such a great idea, how come noone but you figured it out until now, EyeAm?
But then, don't bother. I find this discussion out of time, place as well as reason. Go back to writing buzzword filled mockups of your imaginary Novio OS or whatever you do, I don't care. Bottomline; it's what you do that counts.
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 135 of 141 | Posted by EyeAm (68.59.54.5) on 25-Feb-2005 22:10:19 | In Reply to Comment 133 (Sammy Nordström):
"For me, one of the most important features about an OS is that it abstracts the hardware from the user as well as software developer without restricting accessibility and control. This is impossible without giving the OS itself full accessibility and control of the hardware. If there would be anything that the OS couldn't do that an application banging directly on the hardware could, then it's a flaw on the behalf of the OS rather than a feature on the behalf of the application, IMO."
If the OS can't do it (when built on an exokernel), the programmer doesn't have to wait until there is a new OS. This model will always keep the OS company interested in staying cutting-edge.
Default OS APIs/modules kept cutting-edge...will be utilized by programmers who can't think of a reason why to make their own (even though the capability or possibility will be there for them to make their own). Choice. Advantage. freedom.
"The exokernel idea has been around for quite some time now and I do believe there is a reason for why noone still hasn't managed to create a successful OS alternative using this kind of kernel design and why none of the mainstream OS alternatives still hasn't even as much as considered to implement it. Atleast noone that I've heard of has, the closest thing being the AmigaOS which has a flaw much like an exokernel that lets applications bang the hardware directly. So, if it would have been such a great idea, how come noone but you figured it out until now, EyeAm?"
Because I am a genius. :)
My intuition never leads me down the wrong path.
I understand that you consider the exokernel model a flaw; I do not. And for you to say "would have been", in an effort to dismiss its proven merits, is asinine. The exokernel efforts are very much alive and well--and such an advantage that the model still causes serious consideration by those who might one day put Windows or MAC OS on one. A lot of computer-minded bright minds have discovered it, including Butler W. Lampson now working over at Microsoft.
Last but not least, let me address your thought that 'Because it hasn't been tried, we shouldn't try it'. :) First, changing an enormous OS such as Windows...would give anyone pause--even if the resulting change would be a better one. To not try things because others haven't...is no reason to not try things, or to investigate their merit. To me, that is 'mob mentality'; and the behavior of followers. It is where otherwise smart people continue to whine about their situation, without trying to change it (i.e., Sassenrath and his PC mouse debacle vs. his refusal to return to Amiga OS, where he knows he can alter the future).
You know, the Amiga community has its share of geniuses; but they've grown complacent over time. They see the problems, but they don't do anything about them. This is going to change :) I hope to rattle enough nerves to initiate this change.
"But then, don't bother. I find this discussion out of time, place as well as reason. Go back to writing buzzword filled mockups of your imaginary Novio OS or whatever you do, I don't care. Bottomline; it's what you do that counts."
I know it is what I do that counts. :) That's why I continue doing it. If you've tired of the discussion, then I bid you adiós, Auf Wiedersehen, arrivederci, Tot ziens, adeus, goodbye, konichiwa, aloha...
The benefits of an exokernel-based Amiga OS are far too great to be ignored by those seriously wanting to compete with what is out there.
--EyeAm :)
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 136 of 141 | Posted by EyeAm (68.59.54.5) on 25-Feb-2005 23:56:20 | Some pointed notes taken from "Exokernel: An Operating System Architecture for Application-Level Management" (Dawson R. Engler, M. Frans Kaashoek, and James O'Toole Jr.--MIT Laboratory for Computer Science, Cambridge, MA)
http://rds.yahoo.com/S=2766679/K=%2Bexokernel+%2BLampson/v=2/SID=w/l=WS1/R=21/IPC=us/SHE=0/H=1/SIG=13ijsjd4f/EXP=1109458796/**http%3A%2F%2Fpeople.cs.vt.edu%2F%7Eshaffer%2FExokernel1.pdf%23search%3D%27exokernel%20Lampson%27
Substantial evidence that applications can benefit greatly from having more control over how machine resources are used to implement high-level abstractions:
1. The high cost of general-purpose virtual memory primitives reduces the performance of persistent stores, garbage collectors, and distributed shared memory systems. (Appel and Li)
2. Application-level control over file caching can reduce application running time by 45% (Cao, et al.)
3. Application-specific virtual memory policies can increase application performance. (Harty and Cheriton; and Krueger, et al)
4. Inappropriate file-system implementation decisions can have a dramatic impact on the performance of databases. (Stonebraker)
5. Exceptions can be made an order of magnitude faster by deferring signal handling to applications. (Thekkath and Levy)
To export resources securely, an exokernel employs three techniques:
1. Secure Bindings (applications can securely bind to machine resources and handle events)
2. Visible Resource Revocation (applications participate in a resource revocation protocol)
3. Abort Protocol (an exokernel can break secure bindings of uncooperative apps by force)
The exokernel has brought the hardware interface (ideally as low-level as possible) to the applications, with the goal of separating protection from management.
The exokernel will protect framebuffers without understanding windowing systems, and disks without understanding file systems, because the exokernel does not need to understand these things. And it is *exporting* hardware resources rather than emulating them like would be the case where each application has its own virtual machine.
"In practice, our prototype exokernel system provides applications with greater flexibility and better performance than monolithic and microkernel systems."
"Traditionally, operating systems have centralized resource management via a set of abstractions that cannot be specialized, extended, or replaced."
"As previously noted by Lampson and Sproul, Anderson et al., and Massalin and Pu, general-purpose implementations of abstractions force applications that do not need a given feature to pay substantial overhead costs. This longstanding problem has become more important with explosive improvements in raw hardware performance and enormous growth in diversity of the application software base. We argue that prefventing the modification of the implementation of these high-level abstractions can reduce teh performance, increase the complexity, and limit the functionality of application programs."
Note: Amiga OS was designed with the phrase "Elegance Through Simplicity" in mind, and the intent for expandability and efficiency. By keeping to these ideas, you can have your speed and power--in fact, it behooves any Amiga programmer to always consider this. In a very real sense, the exokernel makes the OS library-centric and, to extend the metaphor, effectively turns the applications into people walking into a library to borrow a book. They won't borrow every book there, nor will they have to know about every book there--just what they require and want to read. A book may sit there unused for a long time, before someone (in an OS, an application) comes along to use it. But the whole library isn't known by the kernel--particularly important that it isn't at boot-up. :) Now, granted, I've sort of mixed up contexts of metaphors here (OS vs people walking into a library), but I didn't start the 'library os' metaphor to begin with; though, this is what the inventors intended with it. But there you have it.
Exokernel model is far more extensible than monolithic and microkernel models.
In fact, you could set up a boot manager for your most-used apps, and bypass the desktop entirely (by option/preference). You could turn the machine on, have the boot manager on screen=-listing Desktop, Word Processor, MoviePlayer--and you could click your Word Processor to go directly into that immediately, and never have to see the desktop. This would be but ONE customization that could be made.
A lot of things that normally get loaded with a microkernel would not have to be loaded (until actually needed) with an exokernel.
All of this is pointing toward greater *efficiency*, *flexibility*, *speed*, and *Power*, while keeping *size* down to the absolute minimum necessary. Regarding that last part (size), I always think of Edgar Allan Poe's advice regarding the short story, and how the author must remove everything not essential to the story. I recently came across something online that also spoke to the size of computer OSes--that the perfect OS is achieved when you can't take anything else out of it, and it still do the minimum required at the same speed or faster.
--EyeAm
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 138 of 141 | Posted by EyeAm (68.59.54.5) on 02-Mar-2005 09:14:27 | In Reply to Comment 137 (Sammy Nordström):
"Or, it will take away the pressure of having to be cutting edge from the OS company."
"But then, whatever, EyeAm. Whatever..."
Your dismissive tone speaks volumes for your apparent inability to adequately surmise the benefits of the model in question. The beauty of the model maintains a competitive edge, not diminishes ones. It facilitates power in the hands of general programmers and users to gain what they want from the OS, whether or not the OS company will deliver further enhancements after the main box is out the door.
A correlation can be drawn to what happened in the wake of limitations relating to Intuition, and then GadTools, which resulted in improvements on through things like MUI, which addressed deficiencies or lack of foresight in the original OS and extended capabilities.
I maintain that an exokernel-based Amiga OS will put Amiga on a much firmer footing, insofar as speed, flexibility, power, and the ability to expand and introduce greater innovations. Once it is built correctly, the simple but elegant design paves the way for things that could never be done on the Amiga OS before--and certainly not within current competing OSes.
But then, whatever, Sammy. Whatever... :)
--EyeAm
"Sir, Sammy was leaving in a huff earlier, but note how he keeps coming back to stir up the things--he's addicted to negativity."
http://s87767106.onlinehome.us
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 139 of 141 | Posted by EyeAm (68.59.54.5) on 04-Mar-2005 03:22:25 | In Reply to Comment 39 (Don Cox):
"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.)"
I wanted to comment further here--and it's not on the exokernel topic.
I agree with you here about more libraries. The new Amiga OS also needs to have libraries for CGI, Perl, Flash, and other such scripting languages found on the internet, so these things can be utilized globally and within programs. Such an addition would allow for greater ease and flexibility with testing out websites before they go live (and wind up using the online server, and CGI), for example. Another benefit would be with the GUI--like giving text an active glow, via a CGI or DHTML script. Whatever can be done now with webpages on the internet should be able to be done on the new Amiga OS. :) Freebie scripts could be downloaded by users of the OS, and used. And ReAction, which Fleecy said OS4 uses--and I assume OS5 will, as well--could benefit from these same libraries. On an exokernel, of course, apps could go to ReAction, or bypass it and still use these libraries for whatever they wish to present.
--EyeAm
Reply to this comment | Top |
|
Amiga Exec kernel rewritten as exokernel : Comment 141 of 141 | Posted by EyeAm (68.59.54.5) on 04-Mar-2005 03:39:34 | In Reply to Comment 61 (Fabio Alemagna):
"kernel modules"
Hmm. This made me want to clarify what I mean by modules. Anytime I've mentioned 'modules' in this thread or any other on the site, I have not been talking about 'kernel modules' in the sense of things tied to the kernel at bootup. Just to be more clear. :) I know you were talking to someone else in the thread when you mentioned them, but I wanted to make this comment, just in case there was any confusion. When I mention API/modules, I'm thinking User-Level.
--EyeAm
Reply to this comment | Top |
|
[Previous 50] [Top] 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.
|
