LWN: Comments on "MINIX 3.2.1 released"

MINIX 3.2.1 released

Baylink — Tue, 12 Mar 2013 22:08:17 +0000

Well, I thought we got a lot of great political commentary on the last election out of it. :-)

MINIX 3.2.1 released

keesj — Sat, 02 Mar 2013 11:42:25 +0000

>> MINIX 3 allows drivers to crash just like other userland programs under Linux
>Does MINIX support IOMMU when available to really prevent the driver from affecting the rest of the system?

No, this is not supported but would certainly fit design goals of MINIX.

MINIX 3.2.1 released

renox — Fri, 01 Mar 2013 13:45:18 +0000

> Does MINIX support IOMMU when available to really prevent the driver from affecting the rest of the system?

I doubt it, a googling showed this "Not assigned yet":
http://wiki.minix3.org/en/StudentProjects/DependabilityIn...

But Genode/NOVA seems to have it:
http://www.osnews.com/story/26819/Genode_13_02_supports_I...

Microkernels are better

ARealLWN — Fri, 01 Mar 2013 02:23:25 +0000

I believe that power (or powerpc) claims to be a performance optimized risc architecture (source would be Orielly publishing High Performance Computing, second edition). As I understand it that means that they say that they are risc based but will include additional instructions if it seems like they could improve the performance of software written for the architecture. I do appreciate that you have given backing to my initial statements and would like to thank you for doing so.

Microkernels are better

ARealLWN — Fri, 01 Mar 2013 01:57:45 +0000

I was going to type a rebuttal stating how you are wrong and don't know what you're talking about. After carefully reading you're reply I must say that I don't think I expressed my statements clearly the first time and that I believe you are probably correct about Intel being faster. I was trying to state that Intel has not been faster or faster per money invested in the past, not currently. Currently if you want a fast general purpose processor Intel isn't a bad choice. If you want pure processing you can get a gpu but those don't work well as general processing and only work with certain workloads, much like a dsp in the past. I'm not sure if anyone ever made a processing system based on risc and dsp architecture but in the past someone developed a system based on a bunch of TI dsp with 2mb ram on a 72 simm modules (if memory serves) that had the best performance per dollar for it's time. In order to break DES the EFF developed a machine with custom chips which certainly weren't intel compatible but had much better performance. Building a computer with good performance depends as much on what applications you are running as what cpu you choose and which peripherals you put inside it. As far as your reference to the pentium 4 compared to an early alpha processor, I won't comment except to mention that alpha was dead by then as far as DEC was concerned and had been for a while. The engineers had moved to AMD or some other company and the Athlon was competing with that processor very favorably in SPEC benchmarks without needing a 6ghz alu.

Microkernels are better

ARealLWN — Fri, 01 Mar 2013 01:22:50 +0000

I would like to argue that the Itanium chip wasn't really a blunder on the part of Intel. The technical merits of it can certainly be called into question but it killed off the DEC Alpha, SGI's interest in MIPS technology, and the PA-RISC architecture of HP simply with marketing because everyone bought into the idea of EPIC being the future of high performance computing. They eliminated a large class of potential threats to their interests in the server and workstation market before shipping any silicon. That hardly seems like a blunder to me. The easiest way to make sure you win a race is to make sure anyone faster then you doesn't show up. Intel simply diverted attention away from other competition to make certain players who might pose a more immediate risk were out of the equation first. IMHO.

Microkernels are better

deater — Thu, 28 Feb 2013 15:20:07 +0000

> Then why people are not doing it? Take a look on the list once more:

I did. Notice in the November 2012 list that Intel doesn't make the top 5 at all. Yet Power and SPARC do, both considered RISC chips by most people I think (although Power is debatable).

x86 got to the top just because of economies of scale and because it is good enough, relatively cheap. Being able to buy things off-the-shelf does help. Having spent some time in an HPC group I can tell you that x86 is used because it's there, not because it has any real benefits. How long has it taken them to get a fused multiply-add instruction?

Microkernels are better

dlang — Wed, 27 Feb 2013 22:41:58 +0000

I am not trying to say that context switches will be fast, I was merely responding to the logic of why x86 architecture won. It isn't because it's the best, it's because it's had the most R&D effort pumped into it to work around it's problems

This includes to a large extent, being produced on the most advanced fab processes, if you took the competing designs and produced them at the same resolution that Intel uses for their x86 chips, they would be much smaller, cheaper, faster, and use significantly less power than they currently do. The fact that with all these handicaps they are competitive to Intel chips in many uses is a good indication of how bad the x86 architecture is.

Microkernels are better

khim — Wed, 27 Feb 2013 22:07:29 +0000

Since the IMB PC became the standard, any chips that weren't PC compatible became marginal and the popularity -> money -> R&C -> speed -> popularity cycle started.

Sure, but even if you have enough money you are still constrained by law of physics.

With mobile devices NOT being x86 compatible, we are seeing a resurgence in competition at the architecture level again for consumer devices

Sure, but will fast ring switching survive this push? I very much doubt it. Note that POWER (which actully slightly faster then x86 although more expensive) is also not all that fast with the context switches AFAICS.

Microkernels are better

dlang — Wed, 27 Feb 2013 21:51:36 +0000

the fact that the x86 was used on the most common platform meant that there was more money for speeding up the x86 chips, which made them more popular, which provided more money for speeding them up......

This is why small companies like Transmeta folded, they were compatible, but they didn't have the R&D budgets and manufacturing capability to compete with Intel. AMD is barely hanging on, and if Intel hadn't made the Itanioum blunder (leaving the gap open for the AMD-64 chips), I doubt if AMD would have survived.

network effects matter, when everyone is running binary software, being binary compatible matters. Since the IMB PC became the standard, any chips that weren't PC compatible became marginal and the popularity -> money -> R&C -> speed -> popularity cycle started.

With mobile devices NOT being x86 compatible, we are seeing a resurgence in competition at the architecture level again for consumer devices (enabled by Linux's cross platform support), and Microsoft and Intel have been trying for years to ignore and block this, but now they are having to really recognize the competition.

Microkernels are better

khim — Wed, 27 Feb 2013 20:34:40 +0000

Intel won the war because they were the processor architecture used in the ibm pc.

Nope. Intel got money for the war because it built the architecture used in the ibm pc, that's true. But it won the war because it was faster. Do you think developers of monsters in top500 list care about ibm pc compatibility? Nope: they care about performance. And this list was dominated by x86 CPUs for years.

If you want to talk about what was faster, the DEC Alpha was faster then the Pentium.

For tasks with floating point — may be at first, but for tasks which only use integers it was actually slower. And when you compare Alpha 21364 with Pentium 4 HT 3.06… it was no longer faster even for floating point.

You could build a computer with a cheap risc cpu and a dsp that would have much better mips per dollar/pound/franc then something with an intel processor.

Then why people are not doing it? Take a look on the list once more: 75% Intel x86-64, 12% AMD x86-64, 12% IBM POWER, and 1% SPARC. Where are these risc cpus and dsps? Why there are so few of them in the list?

Microkernels are better

hummassa — Wed, 27 Feb 2013 18:57:17 +0000

I think you just revealed your age... ;-)
(and I'm probably half a dozen years older)

Microkernels are better

ARealLWN — Wed, 27 Feb 2013 18:09:51 +0000

Although a number of points you make are accurate, lets at least do our best to not rewrite history. Intel won the war because they were the processor architecture used in the ibm pc. If you want to talk about what was faster, the DEC Alpha was faster then the Pentium. If you want to talk about what was more affordable, Be made a computer with a pair of processors that ran faster then a 386 for less money. You could build a computer with a cheap risc cpu and a dsp that would have much better mips per dollar/pound/franc then something with an intel processor. Intel won because they offered decent price performance which was able to still be reasonably competitive with offers from workstations by having a standardized way to add components to the cpu or motherboard chipset thereby allowing competition to thrive in a commodity market. I thought everyone knew this.

Microkernels are better

khim — Wed, 27 Feb 2013 14:36:52 +0000

How much context do we need per ring?

Enough to distinguish access from ring-0 to the access from ring-3, heh. Either you add tags to all the commands and all the data in the pipelines or you flush the pipeline after flush.

Basically the question is: if "mov [some_address], register" should succeed in ring-0 and fail in ring-3 then how do you detect this? Either you keep this metainformation near the information itself (that is: when you assign registers you now have 2-3-4x more physical registers and thus more complex logic to assign them) or you need to flush the pipeline after ring switch. First approach will mean larger core pieces (and thus slower CPU frequency), second approach will mean slow ring switch.

According to Wikipedia, ring switches can be relatively fast, presumably because they don't need to reload the page table.

The key word here is "relatively". If you flush the pipeline then there are 15-20 ticks stall and in that time CPU can execute about 30-40 simple commands.

Microkernels are better

gmatht — Wed, 27 Feb 2013 14:11:24 +0000

No matter how exactly switching is done it changes context. Either you need more context to keep all rings "in the loop" (which means larger pieces of CPU core which means slower frequency which means slower CPU overall) or you need to load and unload said context (which means ring switch is slow)."

How much context do we need per ring? According to Wikipedia, ring switches can be relatively fast, presumably because they don't need to reload the page table.

MINIX 3.2.1 released

tjc — Tue, 26 Feb 2013 16:01:52 +0000

I changed "proponent" to "advocate" and forgot to changed the "a" to an "an."

My intent was to point out that the word "software" defines an abstract concept and cannot be instantiated as "another software." "A software" is incorrect as well. "Two softwares" is right out.

Microkernels are better

mpr22 — Tue, 26 Feb 2013 10:51:54 +0000

real mode: 16-bit segment register; left-shift segment by four bits and add the offset to get a 20-bit physical address.
16-bit protected mode (80286 and later): 16-bit segment register; when loading a segment register, use the top 14 bits to do a table lookup to get the base address of the segment; add the offset to the base address to get a 24-bit physical address.
32-bit protected mode (80386 and later): 16-bit segment register; when loading a segment register use the top 14 bits to do a table lookup to get the virtual base address and size of the segment; add the offset to the base address to get a 32-bit virtual address, which is then resolved to a physical address either on a 1:1 basis (paging disabled) or via the paging unit.

Microkernels are better

khim — Tue, 26 Feb 2013 10:46:21 +0000

Didn't Intel use that to get round a small address bus? And wasn't it absolutely useless for security?

They are designed to be used for security and, e.g. OS/2 1.x used them for security. Sadly they broken the backward-compatibility on the way: you could use segments solely to extend memory or for security on 80286 — but not simultaneously. 80386 solved that problem but it introduced UNIX-like paging model and everyone forgot about segments.

iirc, assuming a 4K segment, addressing 4K+1 in segment 1 would get you the first byte of segment 2. On Primes, different segment meant different memory.

You can do that on 80386, too: it really depends on how your GDT/IDT/LDT are arganized. You can even change sizes of segments on the fly. Actually this architecture was pretty sophisticated and flexible, but it was pushed to the slow-path (and eventually eradicated in x86-64) when AMD and Intel found out that nobody uses it.

Microkernels are better

Wol — Tue, 26 Feb 2013 10:38:03 +0000

Didn't Intel use that to get round a small address bus? And wasn't it absolutely useless for security?

iirc, assuming a 4K segment, addressing 4K+1 in segment 1 would get you the first byte of segment 2. On Primes, different segment meant different memory.

Cheers,
Wol

Microkernels are better

khim — Tue, 26 Feb 2013 09:56:11 +0000

*:in x86-32 mode, it lost it in the x86-64 mode

It lost it before that. If you'll try to use segment with non-zero base address on Atom you'll see 4-5x slowdown. Other, larger, cores are not affected as much but still some operations become slower. AMD and Intel keep the segmentation supported for compatibility sake, but in reality it was already pushed to the slow-path before x86-64 was introduced. And situation is the same with fancy high-level instructions like BOUND. It's all uneven, of course: BOUND is fast on most AMD CPUs (may be on all, but I've not measured latest AMD creations) but it's fantastically slow on Intel CPUs.

That's what I'm talking about: fat is squeezed out of fast-path to raise CPU frequency.

Microkernels are better

khim — Tue, 26 Feb 2013 09:48:47 +0000

Firstly, you're going on about deep pipelines. Which causes processor stalls. Which was, I believe, a major reasoning for abandoning the Pentium 4 architecture - it was so prone to massive stalls it wasn't true.

Well, it had 31 stages and was able to execute up to three μops. Which meant you need to always have almost hundred μops in flight. It was unfeasible. Today fastest CPUs have 16 stages and can execute up to four μops. That's two times smaller but still is pretty hard to keep all these pipes filled, yes. What's your point? That you can reduce size of the pipe and this will solve most problems? Yes, but speed will suffer: you'll have larger stages in the pipes and they will be naturally slower.

And secondly, while I can't remember / don't know an awful lot about 50-series architecture, I don't understand why ring-switching should be slow. It's something to do with the memory segmentation, but the point was the segmentation gave you fast AND SAFE switching.

No matter how exactly switching is done it changes context. Either you need more context to keep all rings "in the loop" (which means larger pieces of CPU core which means slower frequency which means slower CPU overall) or you need to load and unload said context (which means ring switch is slow).

The Intel architecture won. Intel architecture cannot do a fast ring-switch.

Yes, but why do you think it's coincidence? It's not. The fact that Intel won the war may be an accident, but the fact that architecture which won can't do fast ring-switch is not a coincidence. The very some tricks which brings you more raw speed for the same price (and that is how Intel architecture won) make it harder to have fast ring switch.

Doesn't mean that other architectures can't, doesn't mean that Intel architecture is the best. It just happened to be the one that gained the market share needed for network effects to knock out the competition.

Yes and no. Intel architecture won because it was faster. And it was faster because it used tricks to make smaller CPU core pieces (that's the only way to keep frequency of CPU high enough) and to have smaller CPU core pieces you need smaller number of stuff in them.

If Pr1me hadn't lost out in the market, and had continued development of their cpus, I'm sure they could have taken advantage of all the same things as Intel, and we would expect fast ring-switching as a matter of course.

Nope. To make fast CPU you need to make it's synchronously-executing pieces small. And that means you need to push "useless fat" out of them. You make fast-path which only executes the most important pieces and slow-path which does everything else. Either you keep the machinery needed for optional rare things like ring switch in the fast path or you keep them on slow path. In the first case you have slow CPU (basically CPU has 2-3-4x slower frequency then streamlined AMD's, IBM's or Intel's CPU) in the second case you have slow ring switch.

P.S. PowerPC 601 had 32 KiB cache back in 1992. Latest and greatest Intel's CPU still have 32 KiB L1 cache. Think about it and about implications for fancy techniques (like GC support or fast ring-switching or… whatever can you stuff in the CPU core to simplify life for OS and pplication writers). Twenty years ago "fancy techniques" meant "bigger price" — and thus people used them where price was not the most important aspect. But fifteen or ten years ago (and most definitely today) trade-offs changes and "fancy techniques" started to mean "slower CPU". And people have chosen "faster CPU" over fancy techniques. The fact that all these interesting architectures have died off at that time and were replaced by dull AMD's, IBM's, Intel's (and for some time SGI's and Sun's) creations is not a coincidence.

Microkernels are better

renox — Tue, 26 Feb 2013 09:18:40 +0000

What I find quite amusing in your post, it's that Intel had (a limitated form of) segmentation(*) whereas most other architectures (PPC, MIPS, ARM) don't have it.

*:in x86-32 mode, it lost it in the x86-64 mode

MINIX 3.2.1 released

jbv — Tue, 26 Feb 2013 03:46:16 +0000

Well, it seems my mastery of the English language leaves something to be desired. -_-

You meant to change "As a advocate" to "As an advocate".

Your substitution still only works for humans though.

MINIX 3.2.1 released

jbv — Tue, 26 Feb 2013 03:33:38 +0000

>> Another pointless software
> I'll follow my own advice and correct myself: s/a/an

Uhm, your substitution doesn't seem to improve the sentence?

$ echo "Another pointless software" | sed -e 's/a/an/g'
Another pointless softwanre

What about s/s s/s piece of s/
or s/software/operating system/

Microkernels are better

Wol — Mon, 25 Feb 2013 23:56:54 +0000

Yup, you need to make that fast hardware BUT.

Firstly, you're going on about deep pipelines. Which causes processor stalls. Which was, I believe, a major reasoning for abandoning the Pentium 4 architecture - it was so prone to massive stalls it wasn't true.

And secondly, while I can't remember / don't know an awful lot about 50-series architecture, I don't understand why ring-switching should be slow. It's something to do with the memory segmentation, but the point was the segmentation gave you fast AND SAFE switching.

The Intel architecture won. Intel architecture cannot do a fast ring-switch. Doesn't mean that other architectures can't, doesn't mean that Intel architecture is the best. It just happened to be the one that gained the market share needed for network effects to knock out the competition.

If Pr1me hadn't lost out in the market, and had continued development of their cpus, I'm sure they could have taken advantage of all the same things as Intel, and we would expect fast ring-switching as a matter of course. Iirc, the difference in speed between a same-ring and a ring-switch call (for the second invocation, first was I believe somewhat slower) was pretty near nothing.

The Pentium 4 was the last gasp of the MegaHurtz wars - it wasn't a good architecture - it was a good marketecture which blew up badly in the real world.

Cheers,
Wol

Microkernels are better

Cyberax — Mon, 25 Feb 2013 22:50:01 +0000

I think it has, but it's not used that much because it's not compatible with Linux process model. L4 kernel can use it, though.

It will get more and more complicated as the speeds go up, but it might be actually still feasible.

Microkernels are better

khim — Mon, 25 Feb 2013 21:15:48 +0000

I'm not all that sure Cortex-A15 has fast switching. Previous cores were a joke speed-wise (and even Cortex-A15 is not all that fast: it's fair competitor is Atom, not Core i7). We'll see if it'll retain this advantage in the future when ARM will become comparable in speed to something from AMD, Intel, or IBM.

Microkernels are better

Cyberax — Mon, 25 Feb 2013 20:31:28 +0000

Actually, hardware with fast process switching exists. ARM actually has a version of it, but it's not really used.

Microkernels are better

khim — Mon, 25 Feb 2013 20:08:22 +0000

It assumes it has just two rings available, a privileged ring for the kernel and an unprivileged ring for user space.

And this is related to Intel architecture... how exactly? Intel has four rings.

Okay, in those days 1MHz hardware was fast

Yup - and that's why ring-switching was FAST FAST FAST.

But put a microkernel on modern 50-series-style hardware, with the kernel in ring 0, the drivers in ring 1, and user-space in ring 3, and you'd probably have a system that could give a monolithic kernel a run for its money for speed, and blow it away for security.

For that you need to first make such hardware. Think about it: quarter-century ago 1MHz (Ok, more like 3-4MHz) was "fast" but memory latency was about 150ns and today 1GHz (Ok, more like 3-4GHz) is "fast" but memory latency is about 15ns. How come memory speedup was just 10x but CPU speedup was 1000x? The answer is well-known, of course: bunch of caches and deep, deep, pipelining. This approach is pretty hard to combine with FAST FAST FAST ring switching: either you keep all the data for different rings "in the ready" all the time (which increses latency of, e.g., L1 cache from 3 ticks to 4 ticks) and slow down all the other things by 30-50%, too or you have slow ring switch but fast CPU.

I doubt 30-50% slower CPU with FAST FAST FAST ring switching can beat faster CPU no matter the OS: in the end most of the time spent doing "real work", not CPU ring switching even with microkernel.

Microkernels are better

Wol — Mon, 25 Feb 2013 15:25:25 +0000

Actually, I *don't* think they've met "the reality outside the ivory tower". I think they've met "the reality that is Intel".

Linux is written to be portable across multiple processors, but it started on Intel. It assumes it has just two rings available, a privileged ring for the kernel and an unprivileged ring for user space. And ON INTEL ring-switching is an expensive operation.

I worked on Pr1me 50-series, and Pr1mos was multics-based. The hardware was segmented-memory, and ring-switching was FAST FAST FAST. (Okay, in those days 1MHz hardware was fast! :-)

But put a microkernel on modern 50-series-style hardware, with the kernel in ring 0, the drivers in ring 1, and user-space in ring 3, and you'd probably have a system that could give a monolithic kernel a run for its money for speed, and blow it away for security.

(Pr1mos never got ported to Intel, shame, but I think the 386 (as it was then) was a very poor hardware match and they just couldn't get it to work.)

Cheers,
Wol

MINIX 3.2.1 released

ledow — Mon, 25 Feb 2013 14:04:20 +0000

There's a comment on the Installation page for virtual machines concerning restarting the Lance service, I believe.

But, to be honest, when I see things like "AHCI support", "USB keyboard support", having to restart network services, not getting to partition SCSI disks by default, etc. on that same page, it puts me off even trying.

I know that we can't just suddenly arrive at the cutting edge of technology with something like this but it's still confined to the technology of the 90's and tasks which don't run on "real" computers, as far as I can see. Even the X-server is still quite old and there's no working autoconfig from what I can see (the days of me fiddling with X modelines are long gone, I'm afraid) - certainly the "how to install in a VM" article suggests you get down and dirty with modelines, lose 6 pixel columns, and all sorts of other nastiness just to get a graphical screen.

Though I happen to believe there's nothing *wrong* with MINIX - I'm even sure the kernel design is more secure if the same effort were to go into it as into, say, Linux - I don't see quite what it provides in real life yet. It's still just a toy.

FreeDOS took years to get there but is a viable DOS alternative that's present in the real world (I know of several IT resellers who will give you FreeDOS if you specify "No OS", just so you can verify it works and is what you were given, not to mention the number of BIOS update disks that rely on it and you can pretty much run any DOS program ever on it and have it work just as well as it would under MS-DOS).

But MINIX is still stuck in the dark ages in terms of actual physical hardware support, and user-friendliness, it seems. And if you can't boot it (AHCI support only in this release!) then you can't use it. Hell, Windows XP was the last OS that wouldn't boot from AHCI drives directly and even that had ways to make it happen (usually involving switching to IDE mode first and installing the AHCI driver, then rebooting and putting it back into AHCI mode). Nowadays, computers don't even tend to come with an option to put things back into IDE mode.

I think we do need MINIX in the world, but I'd be much happier if it was a world where it worked on even quite old physical hardware without needing a lot of faffing about.

MINIX 3.2.1 released

ibukanov — Mon, 25 Feb 2013 13:23:31 +0000

> MINIX 3 allows drivers to crash just like other userland programs under Linux

Does MINIX support IOMMU when available to really prevent the driver from affecting the rest of the system?

MINIX 3.2.1 released

adobriyan — Mon, 25 Feb 2013 10:09:09 +0000

> Linux GPU drivers have had support for hang detection and reset for _years_.

Oops inside kernel driver was always either-or event.
If you're lucky, kernel continues to run, no restart needed!

MINIX 3.2.1 released

drag — Sun, 24 Feb 2013 21:02:28 +0000

hehe.

It seems that the biggest problem with all of this is that when the driver crashes it puts the hardware into a bad state were recovery is just not going to happen.

That is why I suppose people don't notice that hang detection and reset exists.

MINIX 3.2.1 released

Cyberax — Sun, 24 Feb 2013 17:22:48 +0000

> Next week, at embedded world, we will be giving a restartability demo (running on ARM) of the crash and recovery of a graphics driver. This is quite unique and unseen feature in the Linux world.
Uhm...

Linux GPU drivers have had support for hang detection and reset for _years_.

MINIX 3.2.1 released

keesj — Sun, 24 Feb 2013 16:33:25 +0000

Hi,

I have started working for the MINIX 3 team about a year ago. I have mostly been busy with the ARM port. Having done a lot of Linux work in the past I think I might be able to answer some questions.

The design MINIX 3 allows drivers to crash just like other userland programs under Linux. If you do nothing special at best your driver will be restated. To make transparent restarability a fact
you need to do some additional work like splitting your drivers to split the program state and the driver itself. This splitting has been done for at least network *and* block drivers. There is more work going on to allow hot replacement of components (The Linux analog would be something like ksplice but better).

Next week, at embedded world, we will be giving a restartability demo (running on ARM) of the crash and recovery of a graphics driver. This is quite unique and unseen feature in the Linux world. I think there is a market for MINIX 3 on ARM. The system is small and simple enough for people to tweak and modify to their own needs.

Hope this helps.

As last tip. If you have problems running MINIX 3 try interacting with the community. The only reason I still have CD's it probably because of MINIX :p

MINIX 3.2.1 released

tjc — Sun, 24 Feb 2013 02:17:21 +0000

I'll follow my own advice and correct myself: s/a/an

MINIX 3.2.1 released

tjc — Sun, 24 Feb 2013 01:45:51 +0000

> Another pointless software

As a advocate of preserving the English language (what's left of it), I implore you: please don't say things like that.

MINIX 3.2.1 released

mabshoff — Sat, 23 Feb 2013 23:41:03 +0000

> I meant running Minix or other toy/research OS under a hypervisor like XEN or KVM that supports IOMMU so Minix could manage a piece of the real hardware like a network card. Such OS can implement complex network protocols or WIFI drivers isolating the rest of the system from bugs there.

Ok, got your point. That certainly makes sense and if for example you think about VFIO coming from the Cisco folks it does not take much imagination why those folks were motivated to do that work since instead of porting their various routing OSes to various hardware platforms just take Linux with KVM and hand control of the networking hardware to the routing OS. That sidesteps the whole GPL issue and isolates the routing OS from the boring hardware bits.

> I hope such setups would be more widespread allowing once again small teams or even a single person to try new OS ideas against latest hardware.

I think it is already happening. I would be hard pressed to name a OS that does not run on VMWare, i.e. Haiku, the Hurd and Minix all run on top of it. Even OS/2 Warp and later is a supported configuration, but I might have thought about some earlier OS/2 releases which IIRC did some strange things in ring 2, but I am too tired to research it at this time.

I am not sure about the quality of those OSes running on top of say VMWare since I recall strange stability issues with FreeBSD 8.3 on some ESXi targets for example, but that is a different problem. Jump five years ahead and I cannot imagine anything but the various hypervisors being a mandatory target platform for any research OS out there. IIRC last year's linux.conf.au had a session about using Linux as the L4sec boot loader for example for some ARM target. That just sounds like an insane thing to do unless you think about what it would take to write all those drivers for L4sec I assume :p.

Cheers,

Michael

MINIX 3.2.1 released

ibukanov — Sat, 23 Feb 2013 23:17:36 +0000

> IOMMU support for something like Hurd or Minix seems unlikely.

I meant running Minix or other toy/research OS under a hypervisor like XEN or KVM that supports IOMMU so Minix could manage a piece of the real hardware like a network card. Such OS can implement complex network protocols or WIFI drivers isolating the rest of the system from bugs there.

I hope such setups would be more widespread allowing once again small teams or even a single person to try new OS ideas against latest hardware.