12

There is an interesting discussion about the early days of Linux at https://www.abortretry.fail/p/the-path-to-linux that includes some of the exchanges between Torvalds and Tanenbaum. One that caught my eye:

The very /idea/ of an operating system is to use the hardware features, and hide them behind a layer of high-level calls. That is exactly what linux does: it just uses a bigger subset of the 386 features than other kernels seem to do. Of course this makes the kernel proper unportable, but it also makes for a /much/ simpler design.

I was under the general impression that every Unix-like operating system pretty much used the features that the 386 and every modern CPU provided: supervisor mode and paged virtual memory.

What other 386 features did Linux use, that other kernels did not? What benefits did it gain from them?

13
  • 4
    I won't swear to it, but at the time, Linux may have been the only OS that actually supported linear addressing, rather than the segment:offset addressing of previous Intel CPUs. Feb 24 at 18:53
  • 4
    HInt may be right there in the original Torvalds email where he says he's using 386 task switching. That right there is so 386 specific - and has such implications throughout low-level facilities like interrupt handling - that its unlikely to have been used by any other OS ported to the 386. And as for native OSes to the 386 - perhaps Windows? - again it would have been hard for them to support two completely different models - 286 vs 386 - but also it was quickly discovered that native x86 task switching was slower than conventional alternatives for what needed to be done.
    – davidbak
    Feb 24 at 19:33
  • 4
    Interesting to note that some of the first comments Tanenbaum made in the (doubly-indirect linked "LINUX is Obsolete" chain) is that the debate is over, the science is settled, and microkernels have won. That hasn't stood the test of time and wasn't even arguably true then.
    – davidbak
    Feb 24 at 19:38
  • 1
    (That actually might be a good question if the answer isn't available by a single web search I don't have time to do: At the very beginning the 386 Linux used Intel architecture task switching. Later it didn't. (Confirm that!) When did the switch occur and why?)
    – davidbak
    Feb 24 at 19:46
  • 2
    And that link to a Q&A I didn't know about kind of talks about why the switch was made to not do it too.
    – davidbak
    Feb 24 at 20:05

1 Answer 1

12

One of Linus’ other posts provides the answer:

PS. Yes - it's free of any minix code, and it has a multi-threaded fs. It is NOT protable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that's all I have :-(.

See the layout in version 1.2.0 of the kernel, alternating task state segments and local descriptor tables.

386 task switching refers to the use of task state segments and task gates. These were an unusual set of features compared to other CPU architectures at the time, intimately tied to x86 segmentation. They were introduced with the 286, and provide hardware support for context switching — the CPU takes care of storing a task’s context and restoring it as necessary.

By the time Linux started being developed, other OS designers had concluded that implementing task switching in software was faster than letting the hardware handle it. Notably, OS/2 didn’t use hardware task switching (see The Design of OS/2, page 39); looking at similar Unix-style operating systems of the time for which source code is legally available, Coherent didn’t either (but its source code wasn’t available in 1991), nor did 386BSD (although that came later so it wouldn’t have influenced Linux).

However, using hardware task switching would seem natural to someone developing a 386 operating system and reading the Intel documentation available at the time. It would also simplify some of the context switching — one might argue that task state setup is complex, but any protected mode operating system for the 286 or 386 needs to set up at least one task anyway, so that complexity can’t be completely avoided. The Linux kernel emerged from Linus’ exploration of 386 protected mode and task switching, so it’s not all that surprising that it ended up using 386 task switching.

One x86 feature that Linux didn’t use, as far as I’m aware, is rings 1 and 2. As far as I remember, it also didn’t rely on segmentation to split memory up; as was typical on 386s, it used a flat memory model.

4
  • 1
    Interesting. I did know that about the 386 task switching (long time ago, even before Linux, I had an Intel component book and read a whole lot in it). Then later I remembered this, especially as Linux was ported very fast to other systems.
    – chthon
    Feb 25 at 11:31
  • 2
    I also wonder, when reading your list of features, how much of the original iAPX 432 team influenced the design and added features that were never used. There seems to be a parallel with the design of the original x86 assembly language and Eric Isaacson's critique of it.
    – chthon
    Feb 25 at 11:35
  • 2
    @chthon - The much more direct influence was the Multics OS architecture and the GE-645+additions -> Honeywell 6180 processor that implemented all of the segmentation and ring architecture (and paging too). The iAPX 432 was much more a capability-based system - even farther out in left field.
    – davidbak
    Feb 25 at 15:53
  • 1
    I agree that reading the manuals you'd think using the full architecture with call and task gates would seem the way to go. It was all fully described, with examples, and so novel and advanced, and the Intel engineers who put it all together obviously knew what they were doing ... - well they did too. It just didn't work out as well as they thought, and other mechanisms were available that they also provided that worked out better.
    – davidbak
    Feb 25 at 15:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .