Talk:Kernel (computer science)

From Wikipedia, the free encyclopedia

You have new messages (last change).
Good articles Kernel (computer science) (reviewed version) has been listed as a good article under the good-article criteria. If you can improve it further, please do.
If it no longer meets these criteria, you can delist it, or ask for a review.
This article is within the scope of WikiProject Computer science.
??? This article has not yet received a rating on the assessment scale.
??? This article has not yet received an importance rating on the assessment scale.
To-do list for Kernel (computer science): edit  · history  · watch  · refresh
  • discuss in deeper details IPC and synchronization: send-receive, set/reset indiv, lock/unlock and others.
  • deeper discussion of context switch, process states, low level scheduling, mechanism of process interrupts handling.
  • deeper discussion (with sections in summary style) of kernel data structures as ready list, pcb, communication channels, address table, channel table (used in parallel/distributed systems).
  • discuss kernel protection mechanisms: hierarchical protection domains (typical of monolitic kernels), or exchanging of page table entries (logic addres + allowed operations bitmask) through efficient IPC (this implements a capability-based protection). analyze pro and cons.
  • discuss the design of device drivers as procedures or as processes
  • kernel differences between uniprocessor and parallel computing.
  • discuss the relations between the kernel and the compiler
  • discuss further design issues of kernels for realtime systems and parallel/distributed systems, as software lockout
  • identify the kernel level of abstraction according to the classic model: hardware, firmware, assembler, OS, application.
  • discuss the actual need for a call stack, and its alternatives
  • discuss differences between processes and threads
  • clearly distinguish and separate between commercial examples and academic studies.
  • present the subject in general terms, without taking some technologies or design choices for granted just because of their commercial diffusion (expecially if they are obsolete, as in the case of supervisor mode).
  • replace inaccurate, wrong or misleading expressions such as "call the kernel".
  • provide a majority of academic sources/references
Priority 1 (top)
Former FA This article is a former featured article candidate. Please view its sub-page to see why the nomination failed. For older candidates, please check the archive.
Peer review Kernel (computer science) has had a peer review by Wikipedia editors which is now archived. It may contain ideas you can use to improve this article.
Other languages WikiProject Echo has identified Kernel (computer science) as a foreign language featured article. You may be able to improve this article with information from the French language Wikipedia.

Contents

[edit] Ext. link removal

Exterminate All Operating System Abstractions -I removed this because it is adobe postscript format, not common enough for the WP. --User:Stevertigo

? PS not common enough? It is used by almost all modern printers and is the basis for pdf. --mav
I put the link back with a link to an automatic PS-to-text translation. The Google cache is spiffy :) Feel free to make the text link the main link and put the original PS version in parentheses if that seems better to you. --Olathe November 15, 2003

[edit] Merging

There's a suggestion on Monolithic kernel that all 3 types of kernel could be merged into this page. could be a goood idea -- there is a certain amount of duplication as all articles touch on the history of kernel development --Tarquin

Ok, done. --Merphant
There is now a great deal of duplication between Microkernel and this article. I'm not sure what the proper protocol is, but this needs to be addressed Timbatron 07:46, 9 November 2005 (UTC)

[edit] Request for clarity

Unfortunately, only the VERY first sentence is comprehensible to the lay reader. The 2nd sentence is this:

"It is a piece of software responsible for providing secure multiplexing and arbitration of a machine's hardware."

WHat....??? Since Multiplex is a lousy article and "arbitration" isn't explained, I am now clueless. Please explain in simpler terms, or define these words. --Tarquin 16:44, 27 Mar 2004 (UTC)

Is it better now? --Dori | Talk 16:49, Mar 27, 2004 (UTC)
Much improved! thank you :) Can you explain a bit what a Hardware abstraction is please? --Tarquin
How about now? --Dori | Talk 16:57, Mar 27, 2004 (UTC)


[edit] Multiplexing?

The use of the term "multiplexing" to describe time management of resources is completely incorrect. "scheduling" would have been a better term as multiplexing is a method of encoding communications from several sources to be delivered over a medium and then decoded as necessary. It is a networking term which does not describe the inner workings of a computer operating system. I can't edit the part before the introduction. Someone fix it!

Thank you for your suggestion regarding [[: regarding [[:{{{1}}}]]]]! When you feel an article needs improvement, please feel free to make whatever changes you feel are needed. Wikipedia is a wiki, so anyone can edit almost any article by simply following the Edit this page link at the top. You don't even need to log in! (Although there are some reasons why you might like to…) The Wikipedia community encourages you to be bold. Don't worry too much about making honest mistakes—they're likely to be found and corrected quickly. If you're not sure how editing works, check out how to edit a page, or use the sandbox to try out your editing skills. New contributors are always welcome. --Maru (talk) Contribs 04:34, 5 November 2005 (UTC)


[edit] New type of kernel added

I added a 4th kernel type, the "Hybrid kernel" (modified microkernel). It is the type employed by many modern operating systems, most notably Windows NT 4/2K/XP/2K3, and Mac OS X. Neither OS fit really well into either the "Microkernel" or the "Monolithic kernel" categories. I also modified the bit under monolithic kernel that talks about modular kernels, so that the page no longer claims them to be what they are not (hybrid kernels).

I am not entirely sure who's responsible for using this term for modular monolithics, but the earliest reference that I myself have found is in the documentation for Red Hat Linux 6.1. Everything else I've ever read refers to "hybrids" as I've described them. ----MJA 21:36, 10 Apr 2004 (UTC)


[edit] BeOS Debate

I've already changed this once, because the official documentation I've read indicates that BeOS is a microkernel-based OS. I would like to settle this here rather than get into a revert war, because one particular user (67.165.114.246) keeps removing BeOS from the Microkernel OS subsection. He has not provided any documentation to justify this, except to cite developer Travis Geiselbrecht's opinion.

Can anyone verify this? I can't find any sources that say it's *not* microkernel-based, other than various forums and weblogs, which aren't very authoritative. --Nickster

From the OpenBeOS site: FAQ
"NewOS, by contrast, is a new microkernel written by Travis Geiselbrecht (a former Be engineer). Its design is fairly similar to the (modular monolithic) design of the BeOS kernel so it won't require great effort to adapt it."
--AlistairMcMillan 11:16, 11 Nov 2004 (UTC)
I think what 67.165.114.246 might be referring to is an interview Travis did with the Mantova Unix User Group, I seem to remember him talking about the BeOS kernel. However the interview doesn't appear to be available online anymore. [1]
To be clear, Travis did work for Be. I'm not sure if he worked on the kernel though. --AlistairMcMillan 11:36, 11 Nov 2004 (UTC)
Of course Travis's word carries some weight, but I'd be more satisfied by some documentation. I do think user:67.165.114.246 should provide more references before changing the article. If we remove BeOS as a microkernel OS, we should also update the BeOS page to reflect that. That's my concern. -- Nickster 19:08, 11 Nov 2004 (UTC)
I've made changes to the BeOS page. It was an anon editor who originally added the word "microkernel" to the BeOS page here, so I've just pulled it out. Every source I find now says that BeOS uses a modular monolithic kernel, unfortunately none of them are primary. And all the books I have on BeOS seem to avoid categorising the kernel. --AlistairMcMillan 20:49, 11 Nov 2004 (UTC)
Do you consider the BeOS Developer's Guide a primary source? This is official documentation for BeOs programmers, not marketing material. Here is what it has to say:
"The BeOS software lies in three layers: 1. A microkernel that works directly with the hardware and device drivers. 2. Servers that attend to the needs of running applications. The servers take over much of the low-level work that would normally have to be done by each application. 3. Dynamically linked libraries that provide an interface to the servers and the Be software that you use to build your applications."
I haven't found anything official to support the kernel being monolithic, although it does appear to be modular. It looks like it handles the messaging, processes and memory as a microkernel does, with servers handling the GUI, file system, etc. So until there is something substantial to say otherwise, I think it makes sense to use Be's documentation in support of the kernel being a microkernel. --Nickster 22:05, 11 Nov 2004 (UTC)
Unfortunately the Developer's Guide could also be counted as marketing material; would it disagree with the marketing blurb on their website? Does it go into any detail in explaining what makes the BeOS kernel a microkernel? Anyway by primary source I meant one of the actual kernel developers. Although it obviously isn't quite as useful, I think it is telling that all the people who are seeking to re-implement BeOS are quite clear in their opinions that the original didn't use a microkernel.
Anyway as I understand it, the reason people say BeOS didn't use a microkernel is because (some/all?) modules use a shared address space, which means a badly-behaved module can bring the whole system down. --AlistairMcMillan 22:34, 11 Nov 2004 (UTC)
I don't think the Developer's Guide could be called marketing material, at least not without a big stretch. Unfortunately, it doesn't go into kernel architecture, only the interfaces. The developers are definitely the ones who would know, but Travis at least doesn't describe the NewOS architecture on his SourceForge site. The Haiku OS FAQ says the design is a microkernel with a "design fairly similar to the (modular monolithic) design of the BeOS kernel," but that doesn't explain why NewOS is a microkernel and BeOS is not.
As to shared address space, that points to BeOS being a hybrid kernel, unless the modules are all servers, which it looks like they are. And that's a design feature of microkernels. If a badly-behaved module can bring the whole system down, but the modules are technically part of the kernel, then that's the same as saying that a badly-behaved kernel can bring the whole system down, which is self-evident. --Nickster 23:36, 11 Nov 2004 (UTC)
Servers != microkernel. Where you run the servers decides whether it is a microkernel. Servers in user address space == microkernel. Server in kernel address space == modular monolithic or hybrid microkernel. --AlistairMcMillan 23:55, 11 Nov 2004 (UTC)
From the BeBook [2]:
"One way you can reduce the risk of your driver causing a general system failure is by putting as much code as possible in user space. Create a driver that loads into kernel space just enough code to handle the low-level interactions that absolutely have to be done in kernel space, then load code into user space to handle the rest of the work."
Drivers in kernel space. Doesn't that suggest BeOS isn't a microkernel. --AlistairMcMillan 00:00, 12 Nov 2004 (UTC)

Actually. Reading that same page of the BeBook, it says that filesystems like BeFS are a type of Kernel Add-on. From Andrew Tanenbaum: If the file system runs inside the kernel, it is NOT a microkernel. --[3] AlistairMcMillan 00:09, 12 Nov 2004 (UTC)

Yes, I would read "kernel add-on" to mean "kernel module." On the other hand, according to Tanenbaum, a microkernel only removes as much as possible from kernel space, not necessarily everything. In his debate with Linus, Tanenbaum said that in a microkernel-based system "most of the OS runs as separate processes, mostly outside the kernel," (emphasis added), which fits the BeBook's description of these drivers and server modules. Incidentally, I wrote to Travis to ask him about this.
You said that "where you run the servers decides whether it is a microkernel," but that doesn't fit with every definition I've seen for a microkernel. Most of the definitions I've seen apply to the architecture and its abstraction layers, separating mechanism from policy. In the case of BeOS, it looks like a microkernel that implements some of the server mechanisms in kernel space, keeping policy at a higher level. --Nickster 01:32, 12 Nov 2004 (UTC)
I'm sorry but one of the reasons for moving code out of the kernel into modules is so that they can be run in a separate address space. So that bad code in whatever module can only take down that module instead of taking the whole kernel down. I don't know what microkernel definitions you've been looking at, but every single one I've seen mentions that. That is what this sentence from our own page is talking about:
"A service server that fails doesn't bring the entire system down; this simpler module can be restarted independently of the rest."
One of the major reasons it can be restarted independently is because it runs in its own address space.
That is why we have Windows NT under Hybrid, because Microsoft moved the GDI, graphics drivers and window manager into kernel space from 4.0 onwards. [4] It's also why XNU is stuck under Hybrid, because it throws their BSD code in with the Mach microkernel in the same address space. [5]
BeOS should be under either monolithic or hybrid microkernel, but definitely not microkernel. --AlistairMcMillan 14:52, 13 Nov 2004 (UTC)
Okay, I have added BeOS kernel to the list of hybrid kernels, with a link to the BeOS article. Hopefully you agree that it doesn't really belong in the monolithic kernels, due to its architecture (message-passing minimal kernel with client/server modular structure). --Nickster 20:18, 13 Nov 2004 (UTC)
I'd prefer a definitive answer either way. But I guess this'll do for now. I've made changes to Comparison of operating systems to make it consistent. --AlistairMcMillan 22:39, 13 Nov 2004 (UTC)


[edit] See also

Why is there, under "See also", a link to Kernel (if one wishes to see the other meanings of kernel, one needs only type it into the "Go" box)? Unless someone objects, I'll remove this shortly. --Itai 15:43, 12 Apr 2004 (UTC)

I suppose it's just a mistake. Most of the time, you remove it and wait and see if someone tells you there is some particular reason (can be technical) to do so. --Taku 20:16, Nov 11, 2004 (UTC)


[edit] Netware- Microkernel or hybrid?

I put Netware in the hybrid category, because while the paper by Major, Minshall, and Powell clearly states that they consider it to be a microkernel, I also have conversations I have had with a software engineer who wrote parts of Groupwise, and he has stated that parts of it seem to be monolithic to him. Any input? Thanks, Marquis111, Feb 10, 2005 3:40 EST


[edit] Another request for clarity

"Monolithic kernels are often preferred over microkernels due to the lower level of complexity of dealing with all system control code in one address space. For example, the Mac OS X kernel (XNU) while based on the Mach 3.0 microkernel, includes code from the BSD kernel in the same address space, in order to cut down on the latency incurred by the traditional microkernel design."

Although most of the paragraph makes sense to me, the part talking about the Mac OS X kernel confuses me: what does it exactly mean by having BSD code in the same "address space"? And why would it be easier? If microkernels are fragmented into smaller servers, then why would adding monolithic code make it faster? --67.70.21.52 03:24, 23 Feb 2005 (UTC)

Adding monolithic code eliminates a fair number of context switches for the functionality that that added code handles.
The address space, I believe, refers to how in monolithic kernels, the kernel is a single blob of object code running, whereas in Micro-kernels, that single blob is broken up and scattered in a bunch of apparently normal, running programs. --Maru (talk) Contribs 04:34, 5 November 2005 (UTC)


[edit] Atypical Microkernel section

Is this section strictly necessary? I don't know enough about AmigaOS to say what distinguishes the Exec kernel from other microkernels like Mach, but in a general sense I think this section needs more detail if it's to remain. --MFNickster 22:44, 7 May 2005 (UTC)

There are a couple of things that might be considered not very microkernel-like. First of all, AmigaOS was designed to run on a computer with no memory protection, so Exec and everything else runs in the same address space. Secondly, programs ("tasks") routinely call functions in the system libraries directly, instead of passing them messages using Exec. And Commodore never claimed that Exec was a microkernel (as far as I know), but rather called the AmigaOS design "microkernel-like".
I suppose the the low context switch overhead could be atypical too, if "generally underperforming" is to be considered a property of microkernels. (Yes, that bit was a joke.)
magetoo 22:30, 20 November 2005 (UTC)

I'm now removing this section, trying to bring more structure in the article. We can't afford to have a section for every kernel out there that is different in some way. Someone already removed the no-kernel section and no the atypical microkernels are gone... But anyway, I'm creating a new section that's called 'Other designs', just take a look at it...Candamir 08:33, 6 July 2006 (UTC)

Since your section has being removed but Exec microkernel deserves a place of its own due to historical and study purposes and has no categorization than being considered "ATYPICAL", and due of the fact it generated an entire family of descendants kernels I re-issued it as category of its own. Sincerely, --Raffaele Megabyte 21:27, 2 February 2007 (UTC)

[edit] Amiga Exec References

Again user JulesH removed Amiga Exec, now the actual excuse is that it is Original Reserch. Here it comes a certain number of references that stated that Exec it is not Original Research at all but a Kernel existing since 1985 with the launch of Amiga and which generated a long bibliography on about it, and various discussions and studies. But certainly it is a famous problem regarding Amiga Exec as being considered a Microkernel or not, and it generated a long time debate.

With a simple google search you all could find hundreds of documents stating that Amiga Kernel it is a microkernel, or at least a microkernel OF SOME SORT (search for example how it is considered in Germany by googlesearching "Bertiebssystem AmigaOS Microkernel or Mikrokernel"). Here came references on about Exec itself:

  • Commodore Business Machines: Amiga ROM Kernel Reference Manual: Exec (1st edition; white cover), Addison-Wesley, 1986. ISBN 0-201-11099-7
  • Commodore Business Machines: Amiga ROM Kernel Reference Manual: Includes and Autodocs (2nd edition; blue cover), Addison-Wesley, 1989. ISBN 0-201-18177-0
  • http://www.basden.demon.co.uk/amiga/amiga.diffnt.html#messaging
  • "The Amiga Exec library provides a real-time message-based multi- tasking environment." Commodore Amiga Rom Kernel Manual: Libraries and Devices book (2nd edition blue cover), Addison Wesley, 1990, in the chapter on Exec Tasks ISBN 0-201-18187-8.
  • Amiga ROM Kernel Reference Manual: Includes and Autodocs (3rd edition; dark gray cover), Addison-Wesley, 1991. ISBN 0-201-56773-3
  • Commodore Business Machines: Amiga ROM Kernel Reference Manual: Libraries (3rd edition; dark gray cover), Addison-Wesley, 1991. ISBN 0-201-56774-1
  • Very interesting it is an article on Byte Magazine: "The Object-Oriented Amiga Exec", BYTE, January 1991, pp. 329-334.

Regarding AmigaOS studied into universities I found with a quick reasearch two documents:

  • Preliminary Slides from Università degli Studi di Roma 1 "La Sapienza", Italia Course in Computer Science, realized for the first lesson (course of 2000?, 2001?) introducing the full course of studies. AmigaOS it is studied into "Classification of Different SO respect to the user" section [Powerpoint file from University of Rome 1, Italy]).
  • Computer Science Concepts course in Monmouth University New Jersey (USA), in Fall 1999/2000. In the end of the page AmigaOS it is been recommended to be studied be studied with departed OS/2 and VMS Course of Computer Science Concepts
  • Google Groups discussion of 1994 from Senior Student of University of Tokyo asking infos to other users regarding the article of Byte about AmigaOS Exec. One responsible from Department of Computer Science of The University of Western Australia partecipating also to the discussion [Discussion in Googlegroups].

Regarding the debate on Amiga as Kernel or microkernel:

  • Tunes.org project people discussed in the recent past about AmigaOS (is TUNES project now closed?) and if it should be considered a Microkernel architecture. In the end of discussion it is stated that AmigaOS kernel it is a "no-kernel by accident" [TUNES.ORG Microkernel Debate].
  • In pages of Tunes.org AmigaOS it is defined as being not even a kernel if we consider the modern sense of the word "kernel" [Tunes.Org AmigaOS].
  • In the debate opposing Andrew Tanenbaum vs Linus Torvalds known in the Linux community as the Tanenbaum/Linus "Linux is obsolete" debates, Peter da Silva from Ferranti International Controls Corporation, Xenix Support Team, stated clearly that Amiga Exec is a Microkernel and that Minix kernel should take example from Amiga Exec structure [Tanenbaum/Linus "Linux is obsolete" debates].

Sure all these references are enough to proof that Amiga Exec should stay in the article regarding kernel for research, historical and study purposes.

If the definition "Atypical Microkernel" does not fit, then lets all together find another formulation for Exec category because it deserves a place of its own for its peculiarity and its atypical features. BUT KEEP Amiga Exec for these three reasons: Historical, Research, Study. With respect, --Raffaele Megabyte 11:51, 4 February 2007 (UTC)

The problem I have with most of this largely comes down to answering the question: what is the significance of this? My personal opinion, based on descriptions I've read is that Amiga Exec was a microkernel. It's structured very much like one, the only real difference is the lack of memory protection. Some people contend that this lack means it's a hybrid kernel. Whichever it is, it fits into one of the existing categories, so we don't need to create a new one for it. So, to put it in, we need to answer the question why the reader should care. Amiga isn't a currently popular operating system, or a technical ancestor of one, so it doesn't seem to be essential to discuss it. Therefore there would have to be something particularly noteworthy about it to include it in this discussion. Why does Amiga merit more discussion than THE or MCP or Hydra or JX or any number of other systems that haven't been discussed in depth here?
Before we can put it back in, we therefore need to decide:
  1. Which category does it fit best into? This is probably more an issue of semantics than a technical one. We have two poorly defined categories that have some overlap, and we could classify it either way. Which was is best for helping a reader to understand it? I think microkernel achieves that best.
  2. What reliable sources do we have that describe it as a microkernel, or otherwise?
    • The Tunes.org pages don't really count, as there is no editorial control of them, which is required by WP:RS.
    • da Silva's message also fails for being self-published, although we could use it as evidence that some developers feel this way (if necessary). Google groups doesn't help for similar reasons.
    • The CBM manuals would be good references for the actual architecture, but probably aren't the best source for an interpretive claim like whether or not the kernel is a microkernel, which is likely to have been influenced by marketing decisions ("microkernel" was an important buzzword in the mid-80s).
    • I haven't been able to locate a copy of the byte article, so can't confirm its contents.
    • Brief mentions in lists of operating systems aren't references
  3. What is there to say about it that is worth saying? That microkernels do not necessarily need to employ memory protection, citing it as an example? That a microkernel that lacks memory protection is usually considered to be a hybrid, again citing it as an example?
These questions aren't easy to answer. JulesH 00:11, 5 February 2007 (UTC)

Amiga Exec existed without problems (until you raised it by removing Exec with no reasons). It is not enough to keep it? At least the best place for it it is this section: Kernel_(computer_science)#Early_operating_system_kernels.

Oh, and perhaps into your objections you forget to mention the discussion of professors asking each othter regarding Amiga Exec and where to find Byte article. Seems that Academic world was once enough interested into Amiga kernel design. Maybe they will be interested again in the future. Sincerely, --Raffaele Megabyte 09:06, 5 February 2007 (UTC)

[edit] NT is a microkernel hybrid?

Is this really true? For instance, does an application get data from the file system via IPC? I don't believe this is the case. Yet I have heard this claim many times; could it be the same as "microkernels are slow"? --Maury 12:04, 5 Jun 2005 (UTC)

NT is definately not a microkernel. By definition, a microkernel provides only minimal operating system constructs such as threading, while user-mode processes provide filesystem support. Refer to the book by Mark Russinovich (of sysinternals fame) entitled Windows Internals 4th ed.. I'm not sure if you can rightly classify the kernel as microkernel or monolithic. Timbatron 07:49, 9 November 2005 (UTC)

[edit] Yes, Servers == microkernel

"Servers != microkernel. Where you run the servers decides whether it is a microkernel. Servers in user address space == microkernel. Server in kernel address space == modular monolithic or hybrid microkernel. AlistairMcMillan 23:55, 11 Nov 2004 (UTC)"

I'm sorry, but this is wrong. Many microkernels run some or all of a server process in kernel-space for performance reasons. But the memory location of the code, user-space or kernel-space, is not the factor that decides whether or not it is a microkernel: it is the operations that the kernel supports that does.

Ehr..so that's why Win XP is under the Microkernel heading? Because this is the first time anyone ever referred to Windows XP as a microkernel based OS; even the Windows XP page calls it a hybrid. --Egregius
For instance, Mach 4 supported both thread migration and co-location as basic primatives. Programs could migrate into the kernel-space on demand. Would you claim that Mach 4 is not a microkernel? Or that it stops being one by setting one flag on one server?
The "hybrid" definition evolved much later in order to classify compile-time decisions in systems that didn't have runtime flexibility. Yes, xnu runs BSD in kernel-space (which makes me ask why they don't just use FreeBSD) but there is no doubt that it is still a microkernel. Hybrid refers to the package, not the system.
So for the BeOS, if the system services truly are provided by separate programs, as opposed to linked libs or similar, then it definitely is a microkernel. --Maury 12:11, 5 Jun 2005 (UTC)
I changed the summary a whole bunch, using more appropriate OS-Design lingo.
  1. Replaced the term "multiplexing" with scheduling, to describe how an OS determines what process can use what.
   "program" to process and gave the "OSspeak" definition for a process.
  1. clarified the role of a hardware abstraction layer in device independence, and defined it rewording some of what was there to
   make it clearer to the layman.
  1. Described how with the use of abstraction processes needn't be concerned with the specifics of the device and that a driver
  2. the interaction with the HAL.
I'm tired.
Any comments, jpvoodoo@hotmail.com

It was:

"In computer science, the kernel is the fundamental part of an operating system. It is a piece of software responsible for providing secure access to the machine's hardware to various computer programs. Since there are many programs, and hardware access is limited, the kernel is also decides when and how long a program should be able to make use of a piece of hardware, which is called multiplexing. Accessing the hardware directly can be very complex, so kernels usually implement some hardware abstractions to hide complexity and provide a clean and uniform interface to the underlying hardware, which helps application programmers."

I changed it to:

"In computer science, the kernel is the core of an operating system. It is a piece of software responsible for providing secure access to the machine's hardware and to various computer processes (A process is a computer program in a state of execution). Since there are many programs, and hardware access is limited, the kernel is also decides when and how long a program should be able to make use of a piece of hardware, which is called scheduling. Accessing the hardware directly can be very complex, since there are many different hardware designs for the same type of component. Kernels usually implement some hardware abstraction (A set of instructions universal to all devices of a certain type) to hide the underlying complexity from the operating sysytem and provide a clean and uniform interface to the hardware, which helps application programmers to develop programs that work with all devices of that type.

The Hardware Abstraction Layer(HAL) then relies upon a software driver that provides the instructions specific to that device's manufacturing specifications."


[edit] Typo?

"No-kernel software is not limited to a single centralizing entry point.uliugk"

What's that blip at the of the last sentence? --Lee Hunter 01:13, 15 July 2005 (UTC)

I checked through some of the histories, and it appears to be vandalism no-one caught. I rm'ed it. --Maru 03:42, 15 July 2005 (UTC)

[edit] XP/NT Microkernel debate

There's a great deal of information in wikipedia implying that the XP/NT kernel is in fact a microkernel. This is specifically refuted in Mark Russonivich's Windows Internals 4th ed. (considered to be an authoritative source). As a result, I've been trying to clear up the articles where XP/NT is refered to as a microkernel OS. If anyone has any comments they'd like to be taken into consideration, I'd appreciate it. Timbatron 07:57, 9 November 2005 (UTC)

[edit] What's with all the merging?

If every class of kernel is merged here, that will discourage in-depth discussion of each class. It will also prevent linking to information about a specific class, as I was attempting to do by redirecting ExOS to exokernel. Gazpacho 22:45, 24 November 2005 (UTC)

I believe the opposite is true, especially because the differences between micro/monolithic kernels can be quite obscure (nanokernels don't exist btw). I don't think redirecting ExOS to exokernel would be a good idea either? Exokernel is a class of kernels, ExOS an implementation. (I will the perform the merge Real Soon Now ;) ). —R. Koot 22:50, 24 November 2005 (UTC)
Also, at the moment microkernel is just an outdates version of kernel, and there is the risk that this would happen in the future agian if we do not merge. —R. Koot 22:52, 24 November 2005 (UTC)
ExOS is not an exokernel, it is a libOS that ran on MIT Exokernel. "Exokernel" is both the name of the specific OS designed at MIT, and of the class. Mediawiki does not support section redirects (which is what I found at Exokernel), so we need to keep the article broken up according to what people need to link to. There are articles all over WP that cover a broad subject in general terms, and then link to articles about specific cases.
I know that the definition of "microkernel" is fuzzy, but there's no reason that microkernel can't discuss the fuzziness. Simply moving text between articles doesn't improve the content. Editing it does. Gazpacho 23:26, 24 November 2005 (UTC)
Yeah, but you need to discuss it here as well... more duplication... I just don't think it will be possible to keep the information "synchoronized" if it is in differnet articles. What about the history section? —R. Koot 23:37, 24 November 2005 (UTC)
... And MediaWiki will be fixed in the future and for the time being I believe the TOC will suffice. —R. Koot 23:39, 24 November 2005 (UTC)

[edit] Article for every kernel type?

As far as I've seen, the types microkernel, nanokernel and exokernel do have their own article. Shouldn't we create an article also for monolithic kernels and for hybrid kernels and so just leave a bit of information in there that is really neccessary to get an overview of the theme and then include references to the main articles? Because if someone only wants to investigate about the microkernel/monolithic kernel debate, he probably wouldn't want to know about details of monolithic ones. I'm going to wait a few days for you guys answering on my post, but if noone answers, I shall create the articles myself. Actually, I would create the articles myself, just give me green light; here or on my talk page. Candamir 04:41, 3 March 2006 (UTC)

[edit] "compprocesses"?

Has anyone tried reading the second sentence of this article recently? It ends (not including the parenthesised phrase) with "compprocesses", where the "processes" part is a link. I think the "comp" part isn't supposed to be there... Tyrel Haveman 20:49, 5 March 2006 (UTC)

[edit] cross languages

Hello, I am a contributor of the french kernel page. I have some questions to enhance these (english and french) articles, (always possible).

  • Don't you make differences between "micro-kernel" (Mach, L4 ...), "featured micro-kernel" (micro-kernel+services, with a litteral french translation) (xnu, hurd ...) ?

It is hard to explain clearly such kernel concepts without separating these two concepts. Even if we (informatics) usually don't make differences and we use "microkernels" words both for "microkernel based" and "microkernel".

  • You don't introduce reader to basics kernel concepts and goals : memory management, I/O, scheduling ? Is that done "by design"?
  • Do you have more references and biblio ?

---

Hi, if you noticed, I did some housekeeping a few weeks ago by giving each kernel type it's own article. I am more or less fluent in french and read that article and must say that we're a few steps behind... ;) If you don't mind, give me a few hours and come back and see what I've done (only to the english page, I don't dare doing anything in french ;)) Candamir 15:40, 13 April 2006 (UTC)

Ok, I will do so. (Sorry for the delayed repsonse : there is a little time shift between us ... )


We could use some of the pictures, couldn't we? gren グレン 14:01, 14 April 2006 (UTC)
Sure! I have them in odg format if you want to translate it. (I have also created an account on the english wikipedia... v_atekor 14:21, 14 April 2006 (UTC))
BTW, what about the spanish article? I looked at it (I'm fluent in Spanish) and found out that it's basically a stripped-down version of the English version... I'd suggest we first get a good English article and then see what can be done for the Spanish one... Candamir 21:31, 14 April 2006 (UTC)
I saw most "kernel" articles on wikipedia are english translations ( spanish for example). So you are right : improving the english version is priority. ( I am quite better in french and spanish than in english, excuse me for my english mistakes ... ) v_atekor 08:26, 15 April 2006 (UTC)
I think I now finished with the integration of the french content into the English article, the most significant change being the integration of the definition of a kernel and it's tasks. If you're OK with this, we might remove the cross-language tag on top of this article. --Candamir 22:13, 21 April 2006 (UTC)

[edit] Kernel / OS

There are *many* mixes between kernel and general OS goals. For ex. a driver can be a user land program. (Even if low level IO are provided by kernel). The key point is the cost (time, CPU) of putting software in the kernel or in userland. v_atekor 12:14, 18 April 2006 (UTC)

Well, that is true, specially for device drivers, and I thought I already mentioned it, but it appears as if I didn't... Anyway, device drivers are highly design-specific, I made sure to include that point in that section. I also noticed that someone (forgot who) made some contributions to the introduction section, but didn't notice that some parts of the newly included content would better fit into the tasks of a kernel section. I fixed it now. --Candamir 22:16, 21 April 2006 (UTC)

[edit] Last intro paragraph

I don't like the last intro paragraph...

A kernel might even not be allowed to use all of the abstraction mechanisms it provides to other software[1]. Its central position in an operating system implies the necessity for good performance. This makes the kernel a critical piece of software and makes its design and implementation difficult. However, technology has been created to make kernel programming easier while retaining good performance.

I think that the middle two sentences would better belong into 'introduction', along with a sentence about the difficulties of kernel development, and so I moved the entire section there...

I won't discuss the statement made in the first sentence and in the reference, but even then, I think this phrase does need relocation, but I don't know where it belongs...


I also have my doubts about whether people will understand the concepts behind all this. BTW, a kernel MUST use memory space management, this is one of the greatest hurdles in early kernel development, as one must write position-independent assembler code in order to actually be allowed to use paging/segmentation or any form of virtual addressing.

Mostly right, but not fully right. Most part of a kernel does use managed memory - But the memory manager can not use virtual memory it self ;). For the lack of reentrance : that is obvious for I/O, for example. v_atekor


IMHO, these two sentences should be deleted, as I altogether don't know where they would fit.. Meanwhile, I've left them at the end of 'introduction', together with the entire paragraph...

However, I don't like the last sentence at all... I've been into kernel development pretty deep, and to me it seems that even the pros are still using a text editor and their consoles and some archaic virtual machines (well, it seems to me, but try running a kernel on Bochs and you'll see...), and kernel debugging is one of the most tough tasks you could imagine, trust me... Anyway, whoever wrote this sentence, I'm open to suggestions ;), so, I'll wait a few days and then remove the sentence...

Maybe you even think that the difficulties of kernel development deserve their own section, or that they should be removed at all, I still don't know, so let me know...

Candamir 00:58, 28 May 2006 (UTC)

I'm very new here so please forgive me, and feel free to correct me as needed. I don't like the last paragraph either but I don't like it because it has a reference to something that doesn't involve the article. The way I interpted the last sentence was that the machines that grind glass use kernels but the hubble does not. If this is the case, then why do we include a reference to the hubble when it doesn't involve have anything to do with kernels? In other words, unless we can cite a specific example where a kernel was used with a specific reference, why include it? 06:09, 18 July 2006 (UTC)

The Hubble uses lenses which must be made to low tolerance specs. Maybe the sentence could be made clearer somehow. I agree that proof that low-tolerance applications exist falls outside the scope of the article. - Samsara (talk • contribs) 09:13, 18 July 2006 (UTC)
Again, I am new so forgive my newbieness but what I mean is why include a reference (That is, a URL to another article) when it has nothing to do with the article? AusME 09:20, 18 July 2006 (UTC)

[edit] Please renom when references fixed

Candamir, just wanted to say (since it seems this article won't be fully "fixed" before the FAC nomination ends) that you should renominate as soon as you've addressed the comments (mainly the references, I guess). Let me know when you do. Best, Samsara (talk • contribs) 22:09, 16 July 2006 (UTC)


      • Edit to remove my comment. I meant it to be in the topic above*** AusME 06:09, 18 July 2006 (UTC)

[edit] Auto peer review

[edit] Kernel (computer science)

The following suggestions were generated by a semi-automatic javascript program, and may or may not be accurate for the article in question.

  • The lead of this article may be too long, or may contain too many paragraphs. Please follow guidelines at WP:LEAD; be aware that the lead should adequately summarize the article.
  • Per WP:MOS, avoid using words/phrases that indicate time periods relative to the current day. For example, recently might be terms that should be replaced with specific dates/times.[2]
  • There may be an applicable infobox for this article. For example, see Template:Infobox Biography, Template:Infobox School, or Template:Infobox City.[3] (Note that there might not be an applicable infobox; remember that these suggestions are not generated manually) No applicable infobox... Candamir 20:20, 22 August 2006 (UTC)
  • Per WP:MOSNUM, please spell out source units of measurements in text; for example, "the Moon is 380,000 kilometres (240,000 mi) from Earth.[4]
I have no idea why this is coming up...-Ravedave (help name my baby) 20:45, 22 August 2006 (UTC)
  • Per WP:CONTEXT and WP:BTW, years with full dates should be linked; for example, link January 15, 2006, but do not link January 2006.[5]
  • Per WP:WIAFA, this article's table of contents (ToC) maybe too long- consider shrinking it down by merging short sections or using a proper system of daughter pages as per WP:SS.[6]
  • There are a few occurrences of weasel words in this article- please observe WP:AWT. Certain phrases should specify exactly who supports, considers, believes, etc., such a view. For example,
    • correctly
    • is considered
    • might be weasel words, and should be provided with proper citations (if they already do, or are not weasel terms, please strike this comment).[7]
  • Watch for redundancies that make the article too wordy instead of being crisp and concise. (You may wish to try Tony1's redundancy exercises.)
    • Vague terms of size often are unnecessary and redundant - “some”, “a variety/number/majority of”, “several”, “a few”, “many”, “any”, and “all”. For example, “All pigs are pink, so we thought of a number of ways to turn them green.”
  • Please ensure that the article has gone through a thorough copyediting so that the it exemplifies some of Wikipedia's best work. See also User:Tony1/How to satisfy Criterion 2a. [8]

You may wish to browse through User:AndyZ/Suggestions for further ideas. Thanks, Ravedave help name my baby 02:47, 22 August 2006 (UTC)

[edit] etymology

I notice there's no mention of why a kernal is called that. It's a pretty odd word for a piece of software. Shouldn't this be covered in the article. (I always thought it came from nuts what with the kernal being the bit inside surrounding by the 'shell', but I've no idea if that's true or not). Ydam 12:32, 23 August 2006 (UTC)

I agree, that would be a nice item to add if anyone knows. --I80and 21:33, 28 August 2006 (UTC)

[edit] Unix lines of code count

"As the capability of computers grew, Unix became increasingly cluttered with code. While kernels might have had 100,000 lines of code in the seventies and eighties, kernels of modern Unix successors like Linux have more than 4.5 million lines. Thus, the biggest problem with monolithic kernels, or monokernels, was sheer size."

I find this a little biased, as current estimations of the Windows XP kernal (Hybred) are a lot higher then Linux (Monolithic). However, I didn't change the phrasing myself because I can't remember where and what the exact estimation was. Also, some people may argue that the phrasing is fine. Should this be rephrased? --I80and 22:50, 28 August 2006 (UTC)

[edit] Too much fucking technobabble

No. Really. Sweet lord. This article is only useful to people who already KNOW what a Kernel is, those who don't, won't understand a single word.

Surely the "technobabble" is needed if the article is to fully explain the workings of a kernal... after all, to even understand about a kernal in simple terms, an amount of computing knowledge must be assumed, so why not go into the technical details to make the article complete? Tom H 13:10, 5 September 2006 (UTC)

If people don't understand the "technobabble", they can just follow the internal links to get a quick overview of the phrase. --I80and 17:14, 16 September 2006 (UTC)

[edit] Looking at the article

Just came here from the good article candidates list, but looking at the article I notice a few small issues that I think need correcting. Just so you know, I'm coming at this from a technical perspective. I have a BSc in CS and I'm not afraid to use it. I've been involved in kernel development since the mid 90s, and have written a number of experimental kernels.

In the lead section and elsewhere, the article uses the phrase "userland applications", which strikes me as a particularly geeky phrase. I don't know where the term "userland" originated, but most academic texts on this subject use "user-mode" instead.

The article currently states:

In most cases, the boot loader starts the kernel as a process in supervisor mode,[2] but after initialization, it does not remain as a process as we know it, but instead as a whole set of functions that can be invoked by userland applications to perform operations that require a higher privilege level, such as disk access. Kernel execution streams are a continuation of execution streams of userland processes that are paused when performing system calls and resumed when those return. The initial main kernel stream remains as the "idle process" and "collects" unused processor time.

I know this is a summary of the issue so shouldn't be too detailed at this point, but this strikes me as too much of a generalisation for two reasons:

  • Kernel initialisation doesn't really seem to match up completely with the concept of a process to me. It's just code that happens to be executing; depending on the architecture you may set up some kind of process control block for it, but this isn't really necessary (e.g. a kernel I've worked on in the past which used IA32 task switching created the first TCB for the 'init' process, not the kernel). I'd be happer with calling it a thread, but I think to call it either is slightly misleading.
  • I imagine for somebody unfamiliar with kernel code this would be a rather confusing paragraph
  • It also completely ignores the fact that kernel code may execute in response to interrupts, as well as in response to system calls.
  • The last sentence isn't necessarily true. There's no reason a kernel couldn't initialise an additional process to run as the idle process; it doesn't have to be part of the kernel that does this (although I'll admit I cannot find an example of one which does this).
A kernel might even not be allowed to use the abstraction mechanisms it provides to other software. Many reasons prevent a kernel from using facilities it provides, such as: interrupt management, memory management and lack of reentrancy, thus making its development even more difficult for software engineers.

Nobody's holding a gun to its head and saying, "I'm not going to let you do that." Due to design decisions or technical infeasibility, a kernel may not be able to do these things. I also fail to see why interrupt management would prevent a kernel from using its own facilities.

Tasks of a kernel: (Not to be confused with "kernel tasks", a phrase sometimes used as a synonym for "kernel threads" -- perhaps a different title would be better for this section: "Kernel responsibilities" perhaps?)

  • "the kernel must manage the Input/Output (I/O) of the motherboard," Huh? Obviously there's more to IO than just the "motherboard", and of course not all computers are constructed in a way that they even have a motherboard.
  • "userland" used again here, and linked again. Links should only really be used the first time the term is used.

Process management:

  • "To run an application, a kernel must load the file containing the code for the application to memory (and eventually set up its own address space), set up a stack for the program and branch to a given location inside the program, thus starting its execution."
    • For many operating systems, this is backwards. Typically, the address space will be set up *first*, and the code memory-mapped into it, so that pages of the program are loaded on-demand. Also be aware that not all architectures use stacks, and not all operating systems provide their processes with independent address spaces, so saying that these things "must" happen is overstating the case. "Typically" would be a better choice.
    • There's a {{fact}} template here, that could be resolved by pointing the reader to a general reference work, e.g. Tanenbaum or Silberschatz&Galvin.
  • "Typically, the number of processes a system may run simultaneously is equal to the number of CPUs installed (however this may not be the case if the processors support simultaneous multithreading).[citation needed]"
    • Personally, I'd have thought this was self-evident, but someone clearly wants a reference; again a basic textbook should cover this.
  • discusses pre-emptive multitasking in depth, but doesn't mention the alternative of cooperative multitasking.
  • "The kernel must also provide these processes a way to communicate; this is known as inter-process communication (IPC) and is realized through message passing, pipes, synchronization, shared memory, remote procedure calls (RPC) and/or software interrupts.[citation needed]"
    • It's entirely feasible to produce a working kernel with no IPC. Modern kernels typically provide IPC, but it isn't necessary, and may well be missing from special-purpose kernels (e.g. for embedded systems). Again, this should be "typically". Also, other possible IPC mechanisms exist (sockets, perhaps?) so implying the list is complete is misleading.
  • "To allow a kernel to run on such a system, it has to be extensively modified to make it "re-entrant" or "interruptible", meaning that it can be called in the midst of doing something else."
    • "Interruptible" means something different (although somewhat related). Also why "modified"? A kernel could be written from the beginning to be reentrant, and many are. The quotes around reentrant shouldn't be there, and the word is typically written without a hyphen.
  • "The kernel must also provide a way to synchronize memory access on different processors, which makes memory management and process management two highly inter-related topics.[citation needed]"
    • I too would like to see a source for this. A couple of obvious flaws:
      • Synchronization is only necessary in the presence of shared memory. A kernel that doesn't allow memory to be shared by simultaneously running processes could avoid this issue. There are also user-mode synchronization methods that are available with most hardware (cf spinlock) that could be used in absence of kernel synchronization.
      • I fail to see what this has to do with memory management. It's an IPC issue.

Memory management:

  • The {{fact}} templates can be satisfied with reference to a general textbook.
  • Programs don't believe anything. "Behave as if" would work better.
  • The second paragraph should probably state that this technique is known as virtual memory.

Device management:

  • "To perform, an operating system (OS) needs access to the peripherals connected to the computer, which are controlled through device drivers, which must be written by the developers and/or be provided by the manufacturers of the hardware. For example, to show the user something on the screen, the kernel relies on its monitor driver (such as VGA or VESA) which is then responsible for actually plotting the character/pixel.[citation needed]"
    • To perform what?
    • If you're going to define OS as meaning operating system, it should be done the first time the term is used, not all the way down here.
    • "monitor driver"? This is an unusual way of putting it.
  • "A device manager first performs a scan on different hardware buses, such as Peripheral Component Interconnect (PCI) or Universal Serial Bus (USB), to detect installed devices, then searches for the appropriate drivers."
    • This is only true of plug & play systems. Older systems and embedded systems typically have a static selection of drivers that is configured at either system build time or by the user when a new device is installed.
  • "Very important decisions have to be made when designing the device management system, as every access involves context switches, making the operation very CPU-intensive and easily causing a significant performance overhead."
    • This isn't necessarily the case. A kernel->device driver call only causes a context switch in a microkernel. Some systems have very low context switching overhead which means that this isn't a serious issue (e.g. if you aren't using an MMU to isolate process address spaces, a context switch could be as simple as a couple of register loads and stores followed by a jump).

System calls:

  • "invoke the related kernel functions either through the inter-process communication system, software interrupts or shared memory.[citation needed]"
    • Or call gates (see IA32 programmers reference), or through a special system call instruction provided by the processor architecture (see the SYSCALL instruction on AMD IA32-compatible processors), or by simply calling directly into kernel code on systems that don't enforce isolation using hardware means, or... you get the idea.

Different kernel design approaches:

  • "More exotic designs, such as nanokernels and exokernels, are mostly investigated by researchers and are not in widespread use." Xen is an exokernel and is in widespread use.
  • "Monolithic systems are easier to design and implement than other solutions" should be supported by a source, as its not obvious and isn't covered by any of the textbooks I've read. I've also read arguments to the contrary -- the fact that drivers in a microkernel can make use of ordinary kernel facilities that are typically not available to kernel code significantly speeds driver development, for instance.
  • "It was originally believed that careful tuning could reduce this overhead dramatically, but by the mid-1990s most researchers had abandoned this approach. Recently, newer microkernels, optimized for performance, have addressed these problems.[5]" These two sentences are apparently self-contradictory, as the first implies that it is now generally accepted that this isn't possible, and the second that it has been achieved.
  • "Monolithic kernels tend to be easier to design correctly, and therefore may grow more quickly than a microkernel-based system." Correctness is typically considered one of the benefits of a microkernel, because it is easier to be sure that a smaller codebase is correct, which makes this statement rather non-intuitive, so it really needs a source. In fact, this entire paragraph lacks sources. "There are success stories in both camps," for instance, should be followed by two footnotes, with a link to one of each, IMO.
  • "However, the monolithic model tends to be more efficient through the use of shared kernel memory, rather than the slower message passing system of microkernel designs." Microkernels aren't restricted to message passing as their IPC mechanism. Many use some variety of RPC, for example (see, e.g. Spring operating system).

History: This section is great. I don't think a thing needs to be changed about it, except perhaps information about a few experimental kernels that have influenced the way modern computers work.

Sources:

  • I'm not comfortable with the links to 'osdever.net' being used as references. These are apparently self-published documents and I see no credentials to establish the authors as experts. I would recommend:
    • For the micro/monolithic kernel distinction, add similar diagrams to the linked document to the article, and refer to an academic textbook (e.g. Tanenbaum) on the distinctions. Or, if an online source is prefered, perhaps this one, which is written by a named individual with an explicit association to a reasonably well-known university, and as a side benefit is substantially more in-depth than the current source.
    • Complexity of kernel writing ---- not entirely sure what to do with this; leave it in perhaps, as the notion is more than adequately supported by the rest of the text anyway.
    • "programs are loaded for execution and store their data for fast access [in memory]"; surely some university has computer architecture lecture notes on the web somewhere? That would be better than the current reference.
  • A lot of basic stuff isn't covered by anything in the references section. I'd suggest promoting one of the introductory textbooks from the 'further reading' section to a general reference for the entire article. My preference is for Operating System Concepts because I have a copy of the 4th edition and know what it covers, but I'm sure some of the others cover the ground equally well.

I hope all of this is useful! JulesH 11:10, 25 September 2006 (UTC)

OK, I've mostly fixed these problems now. I'm still not thrilled with the sources; we're still using osdever.net in at least once place, and there are still a couple of statements that I think need further sources, but I reckon it's a lot better now than it was. JulesH 12:27, 10 October 2006 (UTC)

[edit] GA status

This is on hold for the following reasons: find valid footnotes for all the citation needed tags. Other than that, pretty good. Rlevse 19:10, 2 October 2006 (UTC)

Failed GA due to no response to concerns are requisite 7 days waiting. Rlevse 20:06, 9 October 2006 (UTC)

[edit] Reverted contributions by User:BMF81

I've reverted a number of changes by User:BMF81 because:

  • I found the contributed text hard to understand. I think this is for two reasons:
    • It gets very technical very quickly
    • I think BMF81's primary language is Italian, and some of his sentence structures are confusing and in a few places he has used words that just don't make any sense.
  • He moved a lot of text about resources managed by the kernel out of the kernel responsibilities section, and I think it works better there as a brief summary of the types of resource before going into depth about each in the subsections devoted to them.
  • Some of it is just plain strange, e.g. "There are two main apporches to the design of a kernel: minimal kernel (commonly called microkernel) or kernel with policies". I've never heard either of the two bolded terms used, and "kernel with policies" doesn't even vaguely make sense to me.

I've put the bulk of his contribution in here, so that we can discuss if there is anything important to save from it. JulesH 21:40, 10 October 2006 (UTC)

(start quoted text)

In the typical vision of the computer architecture as an abstraction layers structure, where each level provides to the above levels a set of resouces and a language to manage them, kernel is the level above the assembler machine; the resouces provided by the abstraction of the kernel include address space, processors, I/O devices, and possibly others depending on the design choices; the language provided by the kernel to manage those resources can be either a concurrent programming language or a sequential programming language with "system calls"[9].

There are two main apporches to the design of a kernel: minimal kernel (commonly called microkernel) or kernel with policies (commonly called monolithic kernel); these two extremes bounds the range of possible approaches, but there can possibly be several intermediate solutions.

...

The kernel's primary purpose is to manage the computer's resources (CPU, memory and I/O devices) to allow the applications to run and use these resources. We can consider the kernel as structured in 3 functional levels:

  1. CPU sharing among processes (called dispatching or low level scheduling). This is the most central part of a computer system, responsible for running or executing programs on it. The kernel takes responsibility for deciding at any time which of the many running programs should be allocated to the processor (which can usually run only one program at once).
  1. Synchronization and interaction among processes.
  1. Management of the resources warped by the kernel. The kernel must provide running programs with a method to make requests to access these resources; it is possible to achieve this abstracting the I/O devices as they were processes of a "special type"; this allow the functional level of process synchronization/comunication to be used to perform I/O. This level is present also in a microkernel, but in a kernel with policies it is much more complex.

...

You were a bit offhanded with your revert: you moved out everything, even the books in the reference section :-O

The paragraph about the kernel abstraction layer is more correct and precise than the current one in the intro; at most it should be moved down in the article since it gets into much detail (the same can be said for the current one).

As a general criteria "i don't understand this, therefore I move it out" I don't think it's a good one, also because a deep understanding of the computer architecture is usually not reached in the undergraduate classes, but in the graduate ones; particulary in the field of OS kernel there's a lot of misconceptions that have no basis in academic studies.

I agree with you that "minimal/with policies kernel" are not common terms, I'll provide some academic reference to proper terminology.--BMF81 16:15, 11 October 2006 (UTC)

OK, now I've had a chance to review this, I've made a few changes in line with your suggestions:
  • Try to emphasize that the kernel is the first abstraction layer over the base hardware in the lead section
  • Mention synchronization & IPC in kernel responsibilities
  • Restore the references
I haven't included the conceptualisation of the kernel as providing a language that can be used by processes to control the computer. I think the core idea here is already expressed (that the kernel is an abstraction layer used by applications to manage the hardware of the computer), and the rigid formal approach that this language suggests would probably confuse most readers of this article.
I've also not included the concept of abstractions of devices as 'processes of a "special type"', because that's an implementation detail that doesn't belong in that section. JulesH 19:56, 11 October 2006 (UTC)
allright, we're moving foward :) --BMF81 07:35, 12 October 2006 (UTC)

[edit] Article structure

To structure the article we should follow Wikipedia:How to structure the content, particulary in the "spiral out" part; the article already tries to achieve that in some way, but it think something is missing. Other than sections "Kernel responsibilities" (that deals with the core aspects of the topic) and " Different kernel design approaches" (with gives a broader vision of the topic), I think we sould have another one dealing with design choiches in single aspects like fault tolerance, priviledges assignation, performance, delagations to the compiler, type of language used to write the kernel, and others.--BMF81 07:35, 12 October 2006 (UTC)

Good idea. I've been thinking about how to bring into the discussion the notion that there are other ways than memory separation to achieve process isolation (e.g. use of a type-safe language for all applications); this can be brought in under the general heading of 'delegations to the compiler'. JulesH 07:49, 12 October 2006 (UTC)
The name I came up with is "kernel design facets", but any better title is of course welcome.--BMF81 09:08, 12 October 2006 (UTC)

[edit] Diagrams

I've been looking at the French version of this article, and they have *much* better diagrams than we do. Anyone feel up to making translated versions...? :) JulesH 11:07, 13 October 2006 (UTC)

I agree, and I'm working on translating [[6]]. However, not speaking a word of french, I'm stuck on what matèriel means. If someone can enlighten me, I can upload it. --I80and 22:35, 1 November 2006 (UTC)

Scratch that. I'm not sure if I'm supposed to erase my last comment, but oh well. I'm assuming matèriel means hardware (which seems likely). It should be on the page now. --I80and 22:45, 1 November 2006 (UTC)

[edit] Cleanup

The article has been tagged for cleanup. Can somebody suggest areas that need work, because I don't really see anything myself that warrants this. JulesH 07:56, 20 October 2006 (UTC)

I agree, if no specific reason is given, I'm for the removal of the tag.--BMF81 13:08, 24 October 2006 (UTC)

[edit] Concurrency paradigms

For explicit concurrent interaction there are just two approches: shared memory (also called global domain) and message passing (also called local domain). Remote procedure calls belongs to the message passing paradigm. This is also stated in the articles for concurrent computing and remote procedure calls.

This to clarify the change in section Process_management --BMF81 11:42, 20 October 2006 (UTC)

I there's no objection I'll remove the mention to rpc.--BMF81 13:07, 24 October 2006 (UTC)
Go ahead. I added it back in because there are ways of implementing it that don't fall under the traditional technique called message passing, but I suppose they are in a way just a variant method of implementing message passing. JulesH 14:52, 24 October 2006 (UTC)

[edit] Unclear sentence on capabilities and indipendent addres spaces

I added the verify source template to this sentence because I find it confusing:

In systems that lack support for capabilities, processes are isolated from each other by using separate address spaces

It seems to soggest that capabilities and indipendent addres spaces exclude each other; insted they are independent chooses and a capability system usually also have indipendent addres spaces.--BMF81 11:29, 26 October 2006 (UTC)

The intention of the sentence is that a system that does not support capability-based addressing at an MMU level would typically use separate memory spaces to isolate protected objects from the user process. I've added a source for the statement. I'll see if I can rephrase it later to try to come up with something easier to understand. JulesH 09:31, 27 October 2006 (UTC)
please provide a detailed reference (page numbers, section numbers, ...), I did't find the cited assertions of Eranian & Mosberger.--BMF81 10:00, 27 October 2006 (UTC)
I'll look at it again when I have more time. Feel free to remove it for the time being if you feel I'm wrong. JulesH 10:57, 27 October 2006 (UTC)

[edit] OSs vs. OSes

I strongly prefer the former, as the latter looks completely wrong to me. Oxford Manual of Style agrees with me:

Most abbreviations form the plural by adding -s: VIPs, MCs, SOSs.

If you disagree, please provide a reference that says otherwise. JulesH 08:21, 9 November 2006 (UTC)

This link provides an adequet majority in favour of 'OSes' over 'OSs'. The term 'OSs' appears to have been a child from when the abbreviation used to have an aprostrophy - OS's. Adding '-s' is absolutely correct for words not ending in 's' (which aren't pluralised by another suffix, e.g. when 'bacterium' becomes 'bacteria'), but when a word ends in 's' it must have an 'es' otherwise it just changes the pronunciation (e.g. 'his' becomes 'hiss', 'oh-ess' (OS) becomes 'oh-esss' (OSs) instead of 'oh-ess-es' (OSes) - I hope that makes sense). RevenDS 16:11, 10 November 2006 (UTC)
I have no idea who these people are. I certainly don't see anything that qualifies them to make this decision. Note that in the examples given above "SOSs" ends with an "S" also. And I'm afraid that, no, your argument doesn't make sense to me. There's no "e" before the last "s" in "Operating Systems", so why should one be included in an abbreviation of the phrase? JulesH 17:58, 10 November 2006 (UTC)
There doesn't need to be an "e" - "Operating System" does not end with an "s". Jakew 18:22, 10 November 2006 (UTC)
It depends how you interprit its meaning. If you think 'Operating System' when you read 'OS', then 'OSs' would make sense. If you just think the two letters making up 'OS' when you read it then 'OSes' makes more sense. This is a grey area, I've discovered. Since I'm outnumbered here, I'll drop the issue for now. On a side note, don't forget that people who write books aren't instantly qualified to make these decisions either. RevenDS 18:39, 10 November 2006 (UTC)

[edit] Unununium

I personally don't believe that this system "entirely lacks a kernel", whatever the creators might say. First, the entire project has the smell of vaporware to me. Second, from their description, I would say that the kernel consists of a python interpreter plus support routines necessary to make it run on bare hardware. Anyone else agree with removing the assertion? JulesH 09:28, 28 November 2006 (UTC)

I've gone ahead and removed it. I think it made the article feel sloppy. JulesH 17:51, 14 December 2006 (UTC)

[edit] Other designs?

Having removed Unununium from the list of "other designs", I've also removed AmigaOS. I've looked up the details of AmigaOS and it seems to me that, depending on your perspective, you could describe it either as a microkernel (if you don't consider memory isolation to be part of the definition of a microkernel) or a hybrid kernel (if you do). I don't think its design qualifies as an entire other category, certainly.

This leaves us with no examples of other designs, and a rather suspect looking statement that other designs exist. Are there any useful examples of such designs? Or should we just remove the statement? JulesH 17:51, 14 December 2006 (UTC)

I've removed it. We can easily add it back in if we find an example. JulesH 11:10, 7 January 2007 (UTC)

Amiga Exec has been accepted as Atypical Microkernel lots of time ago. Why you deleted it? Now it happens that as first step some people declassed to "other designs". But an enciclopedy article deserves to list ALL the examples of microkernels, and mainly those studied as example of design. So Amiga is. Now you Julesh remove it with an excuse because it is the last remaining in the category "Other designs". Unbelivable behaviour.

Amiga Exec it is a library which acts as a kernel. It has inter-process communication (IPC message passing by reference), multitasking preemptive (round-robin) and x and runs in supervisor mode, but it has no services, and it doesn't use Memory Protection. So it could not being considered FULL microkernel but just an atypical form of microkernel. However its design it is studied into Universities for its features and the elegance of the implementation. Many books regarding kernels mention it as of its own. Amiga Exec has also generated an entire family: Original Amiga Exec, AROS version of Exec kernel, and Exec SG (Second Generation) present in Amiga OS 4.0 for PPC processors, which now implements for the first time Memory Protection as any Microkernel should have as feature.

So I will re-issue it. With respect. --Raffaele Megabyte 20:56, 2 February 2007 (UTC)

[edit] Opening figure is confusing

The current opening figure (with the three boxes, Software <-> Kernel <-> Hardware) is problematic for several reasons:

  • A kernel IS a piece of software. The top box should probably say something like "Applications" or "Application Software".
  • What on earth is a cat, a rabbit, and a horse doing in the kernel? A reader who is unfamiliar with the term might think this article has something to do with animals. (The fact that they have to be labelled "Modules", something that they don't look like, is a strong indicator that the graphic conveys the wrong meaning.)
  • The diagram could be significantly improved by showing the kernel mediating access to the CPU, memory, and devices rather than just "hardware".

Ka-Ping Yee 22:07, 5 January 2007 (UTC)

  • kernel is software - This is a good point, and should be an easy fix for anyone who's good with SVG. Volunteers?
  • modules - It is a bit odd, but then what should modules look like? They'd have to be labelled whatever they looked like, because there's no universal symbol that anybody reading the article would recognise as being a module. Somebody only has to read the first three words of the article to realise it has nothing to do with animals.
  • separate hardware components - This would significantly complicate the diagram because at this level of detail we'd have to show the distinction that while the kernel merely partitions CPU and memory access for the processes it runs, those processes may access other devices only via the kernel (typically). The current diagram represents abstraction layers, rather than actual system components, so doesn't really need to make this distinction.
JulesH 10:28, 6 January 2007 (UTC)
I've uploaded a new image (just drew it).
  • kernel is software - Fixed.
  • modules - The modules don't need to be in this figure. The point of the figure this early in the article is to show what the role of a kernel is; it doesn't have to go into detail about how a kernel is constructed internally.
  • separate hardware components - The new image has three boxes for hardware. I don't think it looks too complicated; what do you think?

— Ka-Ping Yee 23:20, 6 January 2007 (UTC)

[edit] GA Review

  • The article is well written. It is comprehensible and readable.
    • It follows logical structure, including a good lede and lede image. Hierarchical layout in a long article like this is essential, and well done here.
    • Wikipedia MOS has been followed. There was the expected amount of technical jargon and acronoyms, but not excessive.
    • In most places the jargon was explained, but this could be improved. Some grammar improvements needed.
  • The article seems factually accurate and appropriately cited and referenced. The sources used seem appropriate and look reliable and verifiable. I perceived no original research or uncited opinions.
  • The major aspects of the Kernel seemed to be covered well. The balance of including text versus referencing other articles in many sections is very good, allowing the article to be comprehensive, yet not too long. (although it is a bit long).
  • I saw no POV issues or problems.
  • The article is stable, with no edit wars or vandalism worth remarking on. No proposals pending to merge or split the article exist.
  • The article had six good images. I felt that a few more may be appropriate when working towards FA. Memory Management and System Calls might be good candidates for those. The images all have appropriate licensing rights for Wikipedia.

Comments: My compliments especially to the following for their contribution to this article that help to make it GA: axturk and Ka-Ping Yee for good images, JulesH, BMF81 and Candamir for editing.


  • The article is long, but it is hard to see how it could be consolidated without losing its comprehensive value. This could be a problem for FA, but it not sufficient to block GA, IMO.

Atom 02:42, 10 January 2007 (UTC)

[edit] Amiga

If you want to add information about the Amiga kernel (which would be welcomed, if there is anything useful to say about it), please provide references that are acceptable according to WP:V and WP:RS. This is an article about an academic subject, it would be good to keep it high quality. JulesH 22:31, 3 February 2007 (UTC)


I don't added anything. I just re-issued an entry removed.

Remember that Amiga Exec atypical Microkernel existed until it was moved to "other designs" section together with the so called ununimum, and then removed when ununimum was considered false. But Amiga Exec it is real. So how could we re-introduce it?

I hope you were in good faith when you removed Amiga, but seems to me a strange beahviour to delete a section in which there is at least one entry and stating that there where "no examples of other designs" remaining.

Also I gave enough Referencences in the talk section about Talk:Kernel_(computer_science)#Amiga_Exec_References. Facts and references said that Amiga OS and its kernel are studied into universities. It is enough academical subject to fit this page.

So Amiga Exec should deserve its place in kernels, for historical, research and study purposes.

If some reader who want to study exotic designs of kernels and completely un-aware of the existence of Amiga came into wikipedia and reads article on Kernel, maybe if he/she reads of Exec, then this could help his/her researchs. But if there is no Exec entry then its design it couldn't be of any help to students or scholars.

Perhaps I just spotted that the better place for Amiga Exec should be Kernel_(computer_science)#Early_operating_system_kernels section of kernel article. I hope that moderators could agree Exec could be re-issued there. Sincerely, --Raffaele Megabyte 07:06, 5 February 2007 (UTC)

Amiga was removed from the "other designs" section because it was generally agreed that it was a microkernel, and therefore didn't fit in that section. The section was then removed because there were no longer any other designs for it to discuss.
I don't really see any evidence that Amiga's kernel has seriously been studied in academic circles. It appears that it has, from time to time, been used as an example for undergraduates, perhaps because it is likely to be the only microkernel most of them have experience with. But none of the standard textbooks on this subject mention it as an important example; it is, at best, a sidenote.
Standard textbooks tend to be rather conservative and focus on the current standard solutions, this does not mean that Amiga Exec is irrelevant. Features such as the user/supervisor-mode management, filesystem model (which has similarities to NFS) and other things would merit further research to fully understand their implications and the possible application of similar techniques to other operating systems/kernels. Archprogrammer 12:22, 5 February 2007 (UTC)
To be honest, I really don't consider it an exotic design. It is simply a microkernel that lacks memory protection, and therefore fails to achieve the primary goal of the microkernel design (i.e., isolation between device drivers). I don't see why this would be of interest or use to somebody coming to this page. To give a historical perspective, it might possibly be worth mentioning in History of operating systems, which is a page that needs substantial expansion, IMO.
What then, would you consider an atypical microkernel? If we, as an example, look at the syscall technique used we can immediately see that this is a fundamental difference compared to typical microkernels (the method in itself is not unusual, but the context in which it is used is). I would consider it interesting and useful if I were interested in looking at different types ok kernels and implementations. Amiga Exec can be considered rather extreme and perhaps somewhat of an oddity but not, I think, irrelevant. Archprogrammer 12:22, 5 February 2007 (UTC)
I have never seen an operating system kernel that I would call an "atypical microkernel". I have seen some kernels I'd called microkernels, and I've seen some I'd call hybrid kernels. I don't see any need to describe any of these as "atypical". All kernels vary in some fashion from others, otherwise there would be no point in writing them. Singularity (operating system), for instance, is a microkernel. Like Amiga, it lacks hardware memory protection, although it makes up for this by using some techniques that weren't really available for the Amiga. JulesH 20:13, 5 February 2007 (UTC)
And it certainly doesn't fit in the "early operating system kernels" section, which talks about systems that are 30 years older than it. JulesH 09:15, 5 February 2007 (UTC)

[edit] Further academical references

In the meanwhile I found other academical references, and an entire course regarding Amiga Exec design at Kennesaw State University, Georgia (USA):

[striked thru all documents found not related with Amiga Raffaele Megabyte 02:41, 6 February 2007 (UTC)]

*Accetta, M.J., Baron, R., Bolosky, W., Golub, D., Rashid, R., Tevanian, R.F., Young, M.W., Mach: A New Kernel Foundation for UNIX Development. Proc. of the Summer USENIX. July, 1986.

This source, available online here, doesn't mention Amiga at all. JulesH 20:55, 5 February 2007 (UTC)
  • Amiga Technologies GmbH., Amiga Developer CD v1.1, Schatzruhe,Germany, 1996.
A self-published document, not a secondary source of the kind we need. JulesH 20:55, 5 February 2007 (UTC)

*Campbell, R., Madany, P., Considerations of Persistence and Security in Choises an Object-Oriented Operating System. Technical report UIUCDCS-R-91-1670, March 1991, University of Illinois at Urbana-Champaign.

Available here. Doesn't mention Amiga. JulesH 20:55, 5 February 2007 (UTC)

*Campbell, R., Islam, N., Johnson, R., Kougiouris, P., Madany, P., Choices, Frameworks and Renement. Technical report UIUCDCS-R-91-1712, December 1991, University of Illinois at Urbana-Champaign.

Available here. No mention of the Amiga. JulesH 20:55, 5 February 2007 (UTC)
  • Campbell, R., Johnston, G., Madany, P., Principles of Object-Oriented Operating System Design. Technical report UIUCDCS-R-89-1510,April 1989, University of Illinois at Urbana-Champaign.
Not available online. JulesH 20:55, 5 February 2007 (UTC)
  • Campbell, R., Russo, V., Johnston, G., The Design of a Multiprocessor Operating System. In USENIX C++ Conference, USENIX Association, November 1987.
Also not available online. All four of the previous papers are about a system called CHOICES, which is a real-time distributed operating system using object-oriented implementation techniques. It is not, in any way easily discernable, related to Amiga, other than in terms of having been first developed at approximately the same time. I don't think it's worth following up these references, as they are only likely to contain oblique references to Amiga, if any at all. JulesH 20:55, 5 February 2007 (UTC)
  • Hamilton, G., Kougiouris, P., The Sprint Nucleus: A Microkernel for Objects. SMLI TR-93-14, April 1993, Sun Microsystems Laboratories, Inc.
I can't find a copy of this paper, although I believe I have read it before. Sprint's an interesting system, a microkernel that uses remote procedure calls for IPC, which I believe puts it firmly in the same category of kernel as Amiga Exec. But I don't recall there being any useful information about Amiga in the paper. JulesH 20:55, 5 February 2007 (UTC)
  • Leyens, D., A Choises implementation of the universal scheduling system. Master’s thesis, 1988, University of Illinois at Urbana-Champaign.
Back to this Choices system again. I can't find a copy online, but masters theses are probably not normally useful sources anyway. JulesH 20:55, 5 February 2007 (UTC)
  • Luursema, J., OOSY,een Object Oriented Operating System. Universiteit Twente, December 1990.
I have been unable to locate this paper or any information about its existence other than from the article you cite below.
  • All these references I mentioned above are included as Bibliography in this article available in Postscript, written in Finnish language from Computer Science Department of University of Helsinki (The place where Linux was born) [Olioperustainen Amiga EXEC]. Also available in HTML for a quick verify: ["Olioperustainen Amiga EXEC" in HTML].
I'm afraid I can't read Finnish. The article clearly exists, and Amiga Exec is clearly its subject, but as to its status as a reliable source, I can't comment. There's only one author name. Has this article been peer-reviewed or is it self-published? What kind of article is it? A thesis? A scientific paper? Just somebody's personal documentation about the system? Without answering these questions, the article itself is irrelevant. JulesH 20:55, 5 February 2007 (UTC)
  • There is also a complete original research project in Advanced Computing Systems Course in Kennesaw State University, Georgia (US), College of Science and Mathematics, in Spring 2003. It is hosted directly in the research pages of the Professor Hoganson and it is Powerpoint format: [Amiga.ppt].
Seems to be a student's presentation for the course. Only has two slides on the kernel, spends most of its time discussing the hardware platform (this is a computer architecture course, not an operating systems course) and the reasons for the business's failure. Not relevant for our purposes. JulesH 20:55, 5 February 2007 (UTC)

Original research from the student was used by professor in the course mentioned below. The purpose of the course seems to demonstrate that a computer may have wonderful kernel design, good architecture and OS, but it could reveal itself a business failure at the same time. Raffaele Megabyte 02:41, 6 February 2007 (UTC)

  • Original research was used again by professor Hoganson for a complete course in which, in some lessons (at least one) Amiga was really studied as example of Kernel Design and perhaps business failure. [See powerpoint file here].
Contains a shortened summary of the points in the previous presentation. Again, not really relevant for our purposes. JulesH 20:55, 5 February 2007 (UTC)
  • Structure of Exec was also studied into Atari magazines. Sure it was a great honour for the kernel of Amiga which was a competitor of Atari ST. Creative Computing Magazine Vol.11,No.9/Sept 1985 page 34, What makes it so great! (Commodore Amiga) by Sheldon Leemon. entire article it is available on the web: [Creative Computing Article].
I get a 404 message from this link. Correct link is this one. Basically just states that Exec provides preemptive multitasking. Not useful for our purposes. JulesH 20:55, 5 February 2007 (UTC)

Seems that Amiga it is very popular underground in Universities worldwide, and there are more textbooks and articles mentioning it maybe with some more contents about it. I think it is not so bad at all for those who consider Amiga Exec just "a sidenote on standard textbooks". Other researches on references are running and will be posted when available. Sincerely, --Raffaele Megabyte 17:40, 5 February 2007 (UTC)

I'm afraid I don't see how these links can lead you to this conclusion. JulesH 20:55, 5 February 2007 (UTC)

Striked-trhu all docs of the finnish bibliography not related with Amiga to avoid confusion in readers. Continuing searching documents to proof that Amiga Kernel Design is studied into universities and other institutes. For example I truly have testimonies that it was studied in almost 3 italian universities, but I can't proof it if I don't find related docs on internet to demonstrate it to all readers. However thank you for your patronage in controlling sources, and for the fact you let me discover Citeseer site which made me found 2 other Exec related articles. Raffaele Megabyte 02:41, 6 February 2007 (UTC)

[edit] Other references

  • Daniel J. Barrett, Lori A. Clarke, Peri L. Tarr, Alexander E. Wise, ACM Transactions on Software Engineering and Methodology, A Framework for Event-Based Software Integration, (1996), University of Massachussetts [[7]]
Extent of discussion of Amiga is the sentence "Several operating systems have event announcement primitives built in to facilitate application integration (e.g. [Commodore-Amiga International Inc., 1992])". JulesH 09:11, 6 February 2007 (UTC)

Look carefully. It deals with AmigaOS one time, 2 times of AREXX script language of Amiga, and at least one or two times of Exec message passing. Raffaele Megabyte 09:46, 6 February 2007 (UTC)

The ARexx reference isn't relevant, as ARexx isn't a kernel level component. While there are frequent ARexx references, that's the only one I could find that referred to kernel-level facilities (and I'm not sure that what was referred to was a kernel-level one, even there; it could have been another reference to ARexx). JulesH 14:13, 6 February 2007 (UTC)
  • Uniwersytet Śląski w Katowicach; Wydział Matematyki, Fizyki i Chemii: AmigaOS – internal structure of operating system. PDF file (in English) avaliable [[8]]
This is a good resource, although like the previous powerpoint presentation I believe it is a student's project, rather than a published academic paper. It is, however, the best overview-level description of the Amiga system I've seen yet. Just a shame it doesn't cover IPC, which I haven't seen described in detail yet. JulesH 09:11, 6 February 2007 (UTC)
  • Amiga Rom Kernel Manual used as reference in a Patent regarding Method and system for passing messages between threads, US Patent Issued on June 6, 2006. Inventor(s) Joseph A. Porkka, Assignee Microsoft Corporation [Link to Patent]. Amiga thread structure of message passing should be very efficient to be quoted as reference of a Patent by Microsoft.
  • Exec 1.2 disassembled in text format. [exec_disassembly.txt] This will help to verify the factuality of statements into Exec Entry in Kernel article of Wikipedia about Exec: It is simple to be re-implemented on various hardware. Code it is small. It is elegant, and its structure it is easy to be learned as example of Kernel programming in University courses. See semaphore structure implementation, memory moving, multitasking, messages, calls for libraries, etc. And perhaps check its weight in bytes once comments were removed.
  • Dr.Dobbs TechNetcast interview to Carl Sassenrath developer of AmigaOS Exec Kernel [Carl Sassenrath Interview].
  • PC Magazine, John C. Dvorak, Inside Track, 22 Oct 1996:

    "...the Amiga OS remains one of the great operating systems of the past 20 years, incorporating a small kernel and tremendous multitasking capability the likes of which have only recently been developed in OS/2 and Windows NT. The biggest difference is that the Amiga OS could operate fully and multitask in as little as 256K of address space. Even today, the OS is only about 1MB in size. And to this day, there is very little a memory-hogging, CD-ROM loading OS can do that the Amiga can't. Tight code--there's nothing like it".

    This excerpt cames from [Wikiquotes by John. C. Dvorak]
Retrieved from "http://en.wikipedia.org../../../k/e/r/Talk%7EKernel_%28computer_science%29_828d.html"