Talk:L4 microkernel family

From Wikipedia, the free encyclopedia

 This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
??? This article has not yet received a rating on the quality scale.
??? This article has not yet received an rating on the importance scale.

Contents

[edit] Major overhaul

Just started doing some major modifications in order to improve the article. I've massaged most of the the text quite a bit, added a lot of text, and also split things into clearly defined sections. There are a number of other changes that would serve this article good:

  • A section (after the background section) describing the concepts behind L4. Thread and IPC, and address spaces and mapping.
  • A separate section related to performance.
  • A section on the use of L4 in industry (and research).
  • Perhaps a more coherent description of the various kernel implementations and APIs would be good. This might just cause even more confusion, though. I don't know.

Still, I believe this is a step in the right direction. --- eSk 18:05, 30 May 2006 (UTC)

[edit] Minor correction

A second look 3rd paragraph: "The overall time for a syscall was less than twice that of Unix, as opposed to five times under Mach." should be: "The overall time for a syscall was less than half that of Unix, as opposed to five times under Mach."

[edit] When was its development's beginning?

In the first paragrpah you write "Since then" but I don't see any mention of a date (or even just a year) anywere in the page. When was its development's beginning? Thanks. Penedo 07:37, 12 May 2005 (UTC)

[edit] Wrong number of lines in the linux kernel

You state that the linux kernel is 33 million lines big.

According to the data in http://www.dwheeler.com/essays/linux-kernel-cost.html it's more around 4,287,449.

This is the reported count on 2.6, presumebly the current kernel as of October 2004 (i.e. 2.6.8.1-2.6.9, according to http://edge-op.org/files/kernel-timeline)

I assume you are talking about the kernel alone, as this is the subject of this article and you reffer specifically to the kernel. If you were reffering to the entire distirubtion, then the same paper at the first link quotes 17 million lines for the entire RH 6.2 distribution (circa 2000). Maybe later versions indeed reach the 33 million figure since the linux desktop has balooned since 2000, but this shouldn't be the number used when reffering to the kernel alone, IMHO.

Thanks for writing such an interesting entry.

Penedo 08:10, 12 May 2005 (UTC)

after a make clean:

/usr/src/linux-2.6.12.3$ find . -type f -exec cat {} \; | wc -l
6792964

—Trevor Caira 11:53, 20 July 2005 (UTC)

Please note that dwheeler's study counted SLOC rather than lines-in-a-file like the cat|wc -l solution does. Of course, microkernel proponents will use the latter rather than the former because, hell, it looks better if you count all the comments as evidence of overbearing complexity too! 62.236.124.118 16:32, 17 May 2006 (UTC)

[edit] Microkernels text not suitable/correct here

I typed "L4" here in Wikipedia search, not "microkernel". Please make the introduction text smaller and move the big text to a suitable article. It should also be noted that the introductions seems to be more a "microkernel fan's" opinion than a scientific paper. Ex:

  • With IPC the operating system can once again be built up of a number of small programs.. Actually, the sentence With pipes the operating system can once again... is also correct. This has nothing to do with microkernels X monolithic kernels, as it was being stated.
  • That system would be considerably easier to maintain; instead of a single 33 million-line kernel. A kernel developed from a microkernel would also have 33 million-line (30 million, 25 million, whatever) kernel. The problem has nothing to do with number of lines. The problem is about code interdependence, isolation, organization, code duplication, etc.

As a whole, the text should be made to conform to higher level standars. --200.208.41.22 02:36, 9 Jun 2005 (UTC)

YES WE WOULDNT WANT TO NOT BE OF HIGH LEVEL STANDARS!!!!111one
I was going to compliment whoever wrote the whole "First generation microkernels" section. (I don't agree with the "microkernel fan" comment above at all.) It is however very long. I'd suggest moving "First generation microkernels" and even perhaps parts of the next section ("A second look") to the Microkernel article. What is already in the microkernel article at the moment seems to only be a duplication of what little is already in the Kernel article on the subject. (And I'd even say it's the "microkernel hater's view".) -- magetoo 00:37, 21 November 2005 (UTC)

[edit] Fiasco still active

My collegues and I at Fiasco development group are in fact not dormant. The information about Fiasco also appears to be rather aged.

[edit] NPOV intro

The intro says:

well known in the computer industry for their excellent performance and small footprint.

I think this is not NPOV the way it's written. Please link to a reference with performance and footprint comparisons, rephrase, move the text down to the main article or remove it. If it stays this way for a long time, it's better to insert a POV check notice in the article. --Hdante 23:34, 12 November 2005 (UTC)

Did you like, check the god damn See Also links? Because it is pretty fucking obvious once you read some of that stuff. --Kintaro 17:41, 30 December 2005 (UTC)
"See also" is not the same thing as "References". If you need one of the documents in that section (presumably the one that is now called "External links") to support a point made in the article, it should be moved to the "References" section at the very least. Probably also given a footnote from the sentence in question. I haven't read the references or the external links so don't know if this is still necessary. JulesH 09:03, 16 October 2006 (UTC)

[edit] HURD

According to HURD: "In 2006, Marcus Brinkmann and associates have met with Jonathan Shapiro (one of the primary achitects of the Coyotos Operating System) to aid in and discuss the use of the Coyotos kernel for GNU/Hurd as there is no focus on L4 anymore." 84.48.58.93 11:27, 10 May 2006 (UTC)

[edit] Monokernal?

Does this mean Monolithic kernel? The word isn't defined or linked, can someone who knows do this please. Gene Thomas 05:00, 28 May 2006 (UTC)

Yeah. Fixed this now. - eSk 17:40, 30 May 2006 (UTC)

[edit] Performance?

Do we have performance stats for more recent hardware than a 486? Performance of IPC calls that need to cross address spaces depend greatly on size of TLB, memory architecture, etc. and may be substantially different in different processor designs. Also comparisons to both (a) IPC calls on a monolithic kernel (e.g. Linux) and (b) system calls on a monolithic kernel (as IPC is used to replace syscalls on a microkernel) would be helpful. JulesH 08:59, 16 October 2006 (UTC)

I concur. Another thing that can have a large impact on this is MMUs. Modern MMUs can (greatly) reduce context switch time and thus would greatly improve L4 performance. More recent tests would be useful here for up to date accuracy reasons. 24.98.124.237 12:25, 9 December 2006 (UTC)Haplo

[edit] L4.sec

L4.sec isn't mentioned in this article at all. L4.sec is a new movement towards adding security to L4 (for various reasons), started as a response to growing security concerns and movements in the capability-based direction (which L4 is not). If anyone gets the time, please include a new (properly cited) section on this. --24.98.124.237 12:29, 9 December 2006 (UTC)Haplo

[edit] Hi

Hi guys,

I am sorry I changed so much; but I think this was neccessary.

I have 2 questions:

1. What do you think about some tables / boxes?

  • Overview of the diffrent API versions
  • Overview of the existing Implementations and its key features

2. I am not sure, but isn't that article still too long and too detailed?

michi.bo a.k.a 141.76.49.44

[edit] OKL4 licensing change

According to http://lists.okl4.org/pipermail/developer/2007-October/000370.html , 1.5.2 and later are licensed under something like the Sleepycat License, which is not a BSD license. I'm not bold enough to stick this in the text without reading the actual license. Yuubi 17:23, 15 October 2007 (UTC)