Linked by Thom Holwerda on Sun 22nd Jul 2007 00:33 UTC, submitted by liquidat
Permalink for comment 257151
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
Linked by Thom Holwerda on 05/17/13 22:15 UTC, submitted by Tom
Linked by Thom Holwerda on 05/16/13 21:41 UTC
Linked by Thom Holwerda on 05/16/13 17:04 UTC
Linked by Thom Holwerda on 05/16/13 13:17 UTC
Linked by Thom Holwerda on 05/16/13 12:06 UTC
More News »
Sponsored Links



Member since:
2005-07-08
Now, it's going back to the Minix model....
Not really... There's no message-passing component to this driver framework. It uses a kernel component to expose kernel data to a userspace component through a pseudo-device and a pseudo-filesystem. The userspace component can behave as though it has access to kernel memory, but the kernel component is actually validating accesses and providing the mappings.
So instead a set of permitted operations, we have a set of accessible memory regions. The result is that programming userspace services is more like programming kernel services, and therefore more convenient. Furthermore, it doesn't require a programmatic interface between components, so stability is very achievable.
In a sense, it rejects the basic premise of microkernel design, which is that unprivileged servers must be restricted in terms of what operations they may perform. We don't care about operations, their names, and their purposes. We only care that unprivileged code doesn't mess with kernel memory that it shouldn't be touching. That's all the isolation that really matters.
Edited 2007-07-22 03:39