Microkernel - Revision history

imported>Corrado72: Adding/removing wikilink(s)

2025-12-20T15:57:40Z

Adding/removing wikilink(s)

← Previous revision		Revision as of 15:57, 20 December 2025
Line 199:		Line 199:
	</ref>		</ref>

	As synchronous IPC blocks the first party until the other is ready, unrestricted use could easily lead to deadlocks. Furthermore, a client could easily mount a [[denial-of-service]] attack on a server by sending a request and never attempting to receive the reply. Therefore, synchronous IPC must provide a means to prevent indefinite blocking. Many microkernels provide [[timeout (telecommunication)\|timeouts]] on IPC calls, which limit the blocking time. In practice, choosing sensible timeout values is difficult, and systems almost inevitably use infinite timeouts for clients and zero timeouts for servers. As a consequence, the trend is towards not providing arbitrary timeouts, but only a flag which indicates that the IPC should fail immediately if the partner is not ready. This approach effectively provides a choice of the two timeout values of zero and infinity. Recent versions of L4 and MINIX have gone down this path (older versions of L4 used timeouts). QNX avoids the problem by requiring the client to specify the reply buffer as part of the message send call. When the server replies the kernel copies the data to the client's buffer, without having to wait for the client to receive the response explicitly.<ref>{{cite web \|title=Synchronous Message Passing \|url=https://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.sys_arch/topic/ipc_Sync_messaging.html \|access-date=3 September 2024 \|ref=qnx_ipc}}</ref>		As synchronous IPC blocks the first party until the other is ready, unrestricted use could easily lead to [[Deadlock (computer science)\|deadlocks]]. Furthermore, a client could easily mount a [[denial-of-service]] attack on a server by sending a request and never attempting to receive the reply. Therefore, synchronous IPC must provide a means to prevent indefinite blocking. Many microkernels provide [[timeout (telecommunication)\|timeouts]] on IPC calls, which limit the blocking time. In practice, choosing sensible timeout values is difficult, and systems almost inevitably use infinite timeouts for clients and zero timeouts for servers. As a consequence, the trend is towards not providing arbitrary timeouts, but only a flag which indicates that the IPC should fail immediately if the partner is not ready. This approach effectively provides a choice of the two timeout values of zero and infinity. Recent versions of L4 and MINIX have gone down this path (older versions of L4 used timeouts). QNX avoids the problem by requiring the client to specify the reply buffer as part of the message send call. When the server replies the kernel copies the data to the client's buffer, without having to wait for the client to receive the response explicitly.<ref>{{cite web \|title=Synchronous Message Passing \|url=https://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.sys_arch/topic/ipc_Sync_messaging.html \|access-date=3 September 2024 \|ref=qnx_ipc}}</ref>

	==Servers==		==Servers==

imported>Guy Harris: /* History */ In at least one document from the OSF, it was referred to as "OSF MK".

2025-09-18T18:07:33Z

History: In at least one document from the OSF, it was referred to as "OSF MK".

← Previous revision		Revision as of 18:07, 18 September 2025
Line 1:		Line 1:
	{{Short description\|Kernel that provides fewer services than a traditional kernel}}		{{Short description\|Kernel that provides fewer services than a traditional kernel}}
	{{Use dmy dates\|date=February 2021}}		{{Use dmy dates\|date=February 2021}}
			{{More citations needed\|date=September 2025}}
	[[File:OS-structure.svg\|thumb\|450px\|Structure of monolithic and microkernel-based operating systems, respectively]]		[[File:OS-structure.svg\|thumb\|450px\|Structure of monolithic and microkernel-based operating systems, respectively]]

Line 94:		Line 95:
	The same mechanisms that allowed the kernel to be distributed into user space also allowed the system to be distributed across network links. The first microkernels, notably [[Mach (kernel)\|Mach]] created by [[Richard Rashid]], proved to have disappointing performance, but the inherent advantages appeared so great that it was a major line of research into the late 1990s.<ref>{{cite web \|title=CMU CS Project Mach Home Page \|url=https://www.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html \|website=www.cs.cmu.edu \|publisher=Carnegie Mellon University \|access-date=8 August 2024}}</ref> However, during this time the speed of computers grew greatly in relation to networking systems, and the disadvantages in performance came to overwhelm the advantages in development terms.{{citation needed\|date = June 2015}}		The same mechanisms that allowed the kernel to be distributed into user space also allowed the system to be distributed across network links. The first microkernels, notably [[Mach (kernel)\|Mach]] created by [[Richard Rashid]], proved to have disappointing performance, but the inherent advantages appeared so great that it was a major line of research into the late 1990s.<ref>{{cite web \|title=CMU CS Project Mach Home Page \|url=https://www.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html \|website=www.cs.cmu.edu \|publisher=Carnegie Mellon University \|access-date=8 August 2024}}</ref> However, during this time the speed of computers grew greatly in relation to networking systems, and the disadvantages in performance came to overwhelm the advantages in development terms.{{citation needed\|date = June 2015}}

	Many attempts were made to adapt the existing systems to have better performance, but the overhead was always considerable and most of these efforts required the user-space programs to be moved back into the kernel. By 2000, most large-scale [[Mach (kernel)\|Mach]] kernel efforts had ended, although Apple's [[macOS]], released in 2001, still uses a [[hybrid kernel]] called [[XNU]], which combines a heavily modified (hybrid) [[OSF/1]]'s [[Mach kernel]] ([[~~OSFMK~~]] 7.3 kernel) with code from BSD UNIX,<ref>{{cite AV media\|url=https://www.youtube.com/watch?v=ggnFoDqzGMU \|archive-url=https://ghostarchive.org/varchive/youtube/20211211/ggnFoDqzGMU\| archive-date=2021-12-11 \|url-status=live\|author=Jim Magee\|title=WWDC 2000 Session 106 - Mac OS X: Kernel\|minutes=14}}{{cbignore}}</ref><ref>{{cite web\|title=Porting UNIX/Linux Applications to Mac OS X\|url=https://developer.apple.com/library/mac/#documentation/Porting/Conceptual/PortingUnix/glossary/glossary.html#//apple_ref/doc/uid/TP40002859-TPXREF101\|publisher=Apple\|access-date=26 April 2011}}</ref> and this kernel is also used in [[iOS]], [[tvOS]], and [[watchOS]]. [[Windows NT]], starting with [[Windows NT 3.1\|NT 3.1]] and continuing with [[Windows 11]], uses a hybrid kernel design. {{As of\|2012}}, the Mach-based [[GNU Hurd]] is also functional and included in testing versions of [[Arch Linux]] and [[Debian]].		Many attempts were made to adapt the existing systems to have better performance, but the overhead was always considerable and most of these efforts required the user-space programs to be moved back into the kernel. By 2000, most large-scale [[Mach (kernel)\|Mach]] kernel efforts had ended, although Apple's [[macOS]], released in 2001, still uses a [[hybrid kernel]] called [[XNU]], which combines a heavily modified (hybrid) [[OSF/1]]'s [[Mach kernel]] ([[OSF MK]] 7.3 kernel) with code from BSD UNIX,<ref>{{cite AV media\|url=https://www.youtube.com/watch?v=ggnFoDqzGMU \|archive-url=https://ghostarchive.org/varchive/youtube/20211211/ggnFoDqzGMU\| archive-date=2021-12-11 \|url-status=live\|author=Jim Magee\|title=WWDC 2000 Session 106 - Mac OS X: Kernel\|minutes=14}}{{cbignore}}</ref><ref>{{cite web\|title=Porting UNIX/Linux Applications to Mac OS X\|url=https://developer.apple.com/library/mac/#documentation/Porting/Conceptual/PortingUnix/glossary/glossary.html#//apple_ref/doc/uid/TP40002859-TPXREF101\|publisher=Apple\|access-date=26 April 2011}}</ref> and this kernel is also used in [[iOS]], [[tvOS]], and [[watchOS]]. [[Windows NT]], starting with [[Windows NT 3.1\|NT 3.1]] and continuing with [[Windows 11]], uses a hybrid kernel design. {{As of\|2012}}, the Mach-based [[GNU Hurd]] is also functional and included in testing versions of [[Arch Linux]] and [[Debian]].

	Although major work on microkernels had largely ended, experimenters continued development.<ref>{{cite web \|title=Redox - Your Next(Gen) OS - Redox - Your Next(Gen) OS \|url=https://www.redox-os.org/ \|website=www.redox-os.org}}</ref><ref>{{cite web \|title=Helios \|url=https://ares-os.org/docs/helios/ \|website=ares-os.org \|language=en-us}}</ref> Using a more pragmatic approach to the problem, including [[assembly code]] and relying on the processor to enforce concepts normally supported in software led to a new series of microkernels with dramatically improved performance.		Although major work on microkernels had largely ended, experimenters continued development.<ref>{{cite web \|title=Redox - Your Next(Gen) OS - Redox - Your Next(Gen) OS \|url=https://www.redox-os.org/ \|website=www.redox-os.org}}</ref><ref>{{cite web \|title=Helios \|url=https://ares-os.org/docs/helios/ \|website=ares-os.org \|language=en-us}}</ref> Using a more pragmatic approach to the problem, including [[assembly code]] and relying on the processor to enforce concepts normally supported in software led to a new series of microkernels with dramatically improved performance.
Line 414:		Line 415:
	* [[Mach (kernel)\|Mach]]		* [[Mach (kernel)\|Mach]]
	* [[Mac OS 7]] to [[Mac OS 9]] ([[Mac OS nanokernel]])		* [[Mac OS 7]] to [[Mac OS 9]] ([[Mac OS nanokernel]])
	* [[Minix]]		* [[Minix]] (abandoned)
	* [[Midori (operating system)\|Midori]]		* [[Midori (operating system)\|Midori]] (discontinued)
	* [[Phantom OS]]		* [[Phantom OS]]
	* [[Qubes OS]]		* [[Qubes OS]]
	* [[Redox (operating system)\|Redox]]		* [[Redox (operating system)\|Redox]]
	* [[Symbian]]		* [[Symbian]] (discontinued)
	* [[SymbOS]]		* [[SymbOS]]
	* [[ThreadX]]		* [[ThreadX]]

imported>OAbot: Open access bot: hdl updated in citation with #oabot.

2025-06-02T06:12:52Z

Open access bot: hdl updated in citation with #oabot.

← Previous revision		Revision as of 06:12, 2 June 2025
Line 247:		Line 247:
	\| location = Cape Cod, MA, USA		\| location = Cape Cod, MA, USA
	\| doi = 10.1109/HOTOS.1997.595177		\| doi = 10.1109/HOTOS.1997.595177
	}}</ref><ref name="Gray_CCMH_05">{{cite conference		\| hdl = 1959.4/39929 \| hdl-access = free }}</ref><ref name="Gray_CCMH_05">{{cite conference
	\|first=Charles \|last=Gray \|author2=Chapman, Matthew \|author3=Chubb, Peter \|author4=Mosberger-Tang, David \|author5-link=Gernot Heiser \|author5=Heiser, Gernot \|title=Itanium—a system implementor's tale \|conference=USENIX Annual Technical Conference \|pages=264–278 \|date=April 2005\|location=Annaheim, CA, USA \|url=http://www.usenix.org/publications/library/proceedings/usenix05/tech/general/gray.html		\|first=Charles \|last=Gray \|author2=Chapman, Matthew \|author3=Chubb, Peter \|author4=Mosberger-Tang, David \|author5-link=Gernot Heiser \|author5=Heiser, Gernot \|title=Itanium—a system implementor's tale \|conference=USENIX Annual Technical Conference \|pages=264–278 \|date=April 2005\|location=Annaheim, CA, USA \|url=http://www.usenix.org/publications/library/proceedings/usenix05/tech/general/gray.html
	}}</ref><ref name="vanSchaik_Heiser_07">{{cite conference		}}</ref><ref name="vanSchaik_Heiser_07">{{cite conference
Line 283:		Line 283:
	\| citeseerx = 10.1.1.25.8376}}</ref> However, this project was never completed.		\| citeseerx = 10.1.1.25.8376}}</ref> However, this project was never completed.

	It has been shown in the meantime that user-level device drivers can come close to the performance of in-kernel drivers even for such high-throughput, high-interrupt devices as Gigabit Ethernet.<ref name="Leslie_CFGGMPSEH_05">{{cite journal \|last1=Leslie \|first1=Ben \|last2=Chubb\|first2= Peter\|last3 = FitzRoy-Dale\|first3= Nicholas\|last4= Götz\|first4 =Stefan\|last5= Gray\|first5= Charles\|last6= Macpherson\|first6= Luke\|last7= Potts\|first7= Daniel\|last8= Shen\|first8= Yueting\|last9= Elphinstone\|first9= Kevin\| author-link10=Gernot Heiser\|last10=Heiser\|first10= Gernot \| date=September 2005 \|title=User-level device drivers: achieved performance \|journal=Journal of Computer Science and Technology \|volume=20 \|issue=5 \|pages=654–664 \|doi=10.1007/s11390-005-0654-4\|s2cid=1121537 }}</ref> This seems to imply that high-performance multi-server systems are possible.		It has been shown in the meantime that user-level device drivers can come close to the performance of in-kernel drivers even for such high-throughput, high-interrupt devices as Gigabit Ethernet.<ref name="Leslie_CFGGMPSEH_05">{{cite journal \|last1=Leslie \|first1=Ben \|last2=Chubb\|first2= Peter\|last3 = FitzRoy-Dale\|first3= Nicholas\|last4= Götz\|first4 =Stefan\|last5= Gray\|first5= Charles\|last6= Macpherson\|first6= Luke\|last7= Potts\|first7= Daniel\|last8= Shen\|first8= Yueting\|last9= Elphinstone\|first9= Kevin\| author-link10=Gernot Heiser\|last10=Heiser\|first10= Gernot \| date=September 2005 \|title=User-level device drivers: achieved performance \|journal=Journal of Computer Science and Technology \|volume=20 \|issue=5 \|pages=654–664 \|doi=10.1007/s11390-005-0654-4\|s2cid=1121537 \|hdl= 1959.4/39966\|hdl-access= free}}</ref> This seems to imply that high-performance multi-server systems are possible.

	== Security ==		== Security ==

imported>Comp.arch at 22:17, 23 May 2025

2025-05-23T22:17:52Z

Show changes