3 ms·

I don't mean to be impolite and I am a BSD fan but you are just trolling here. Lock free path lookups are not a hack. It is a pretty amazing feat IMO. And the

I don't mean to be impolite and I am a BSD fan but you are just trolling here. Lock free path lookups are not a hack. It is a pretty amazing feat IMO. And the fact that it is done for all filesystems transparently in the VFS layer ... You couldn't do that on the Windows NT kernel for example (a microkernel design), because every filesystem driver has to figure out its own path logic there. Linux isn't known for good design all the time but it is a good design.

snvzz 7y ago
>the Windows NT kernel for example (a microkernel design) Windows NT isn't a microkernel design. It does however have some structure to it. Some call it Hybrid kernel, I call it crude layering. It's still better than the spaghetti Linux is. >you couldn't do it Each approach has different tradeoffs. With the microkernel multiserver approach, you get a lot of advantages, such as having a tiny amount of code running in supervisor mode, having strong separation enforced by it, particularly if using the capability model (not to be confused with POSIX capabilities). Possibly formally proven like seL4. It is possible to build a secure system on such a design. It is also possible to build a hard realtime (with proven WCET). It is not possible to do either with a monolith, because of the impossibility of proving the correctness of the monolith inherent to its sheer size and the exponential nature of verification work. In detriment, there's more context switches, which have a cost. But this cost is an order of magnitude smaller on seL4 than Linux, for a solid example. You'd need a severe amount of extra context switches for an actual performance penalty. And seL4 would still have a massive advantage in latency. >but you are just trolling here. No, I am not, and I do not appreciate the accusation. Try and be kind.
- asveikau 7y ago
  You don't have to explain microkernels to me, I know how they work. You could replicate the advantages I describe of path caching in Linux VFS in a microkernel by having some kind of common VFS server, or perhaps write the VFS layer as a library that filesystems consume. This is because micro vs. monolithic is an orthogonal choice to the design. The fact that it has not chosen your favorite approach on that unrelated axis does not make it bad.
  - snvzz 7y ago
    >The fact that it has not chosen your favorite approach on that unrelated axis does not make it bad. It is not possible to implement a general purpose OS on a monolithic architecture. Try as you might you'll always fall short, because it's not possible to do hard realtime on a monolith no matter how much some pretend otherwise (no WCET means no hard realtime. Must have proof of not missing those deadline), nor is it possible to have security (huge TCB, no security. No amount of mitigation can do away with this fundamental problem). And thus, you'll always fall short of general purpose. That's the point I'm making. Linux and all these other systems we use aren't general purpose operating systems. They're just stopgaps. They're due to be replaced. The question isn't if but when and by what exactly.
    - burfog 7y ago
      Well, I guess nothing qualifies then, because you can't have a WCET on commodity hardware. You'd have to have a CPU without any kind of cache (branch history, TLB, etc.) and without any kind of instruction scheduling. You couldn't even have two cores sharing a bus, either on chip or on the motherboard. Due to the above, security is also in question. Spectre and related troubles take care of that. Most people have a very different idea of "general purpose operating systems". It includes Linux. Microkernels have huge problems. Reality disagrees with Andrew S. Tanenbaum. Simplification of components does not come free. Those simple components can have fiendishly complex interactions with each other. Some proven-secure microkernel systems are really insecure because all the buggy code has been shoved into parts that don't count for the security audit. Practical data structure choices become very limited, killing performance. Context switches have always been costly, and the situation has suddenly gotten far worse because we now require Spectre mitigation. Remember also that performance problems are energy use problems. You might be willing to tolerate slowness, but consider battery life and the power fed into huge server farms.
      - snvzz 7y ago
        >Most people have a very different idea of "general purpose operating systems". It includes Linux. A popular misconception is still a misconception. >all the buggy code has been shoved into parts that don't count for the security audit. I hate to repeat myself, but as explained above, at least the microkernel multiserver design has a chance of being secure, because it doesn't run more code than needed in supervisor mode, and isolates components individually. A monolith cannot, because it has an excessively large trusted computer base, which makes cost of proof impractical. >Microkernels have huge problems. Reality disagrees with Andrew S. Tanenbaum. I refer you to the last installment of the Linus-AST debate[0]. >killing performance. I recommend this article[1]. >Well, I guess nothing qualifies then, because you can't have a WCET on commodity hardware. You'd have to have a CPU without any kind of cache (branch history, TLB, etc.) and without any kind of instruction scheduling. You couldn't even have two cores sharing a bus, either on chip or on the motherboard. seL4 has WCET for x86. It simply assumes the worst case for all of this. And it's still a good WCET. I recommend you read the paper[2]. [0]: http://www.cosy.sbg.ac.at/~clausen/PVSE2006/linus-rebuttal.html http://www.cosy.sbg.ac.at/~clausen/PVSE2006/linus-rebuttal.h... [1]: https://web.archive.org/web/20200216184858/https://blog.darknedgy.net/technology/2016/01/01/0/ https://web.archive.org/web/20200216184858/https://blog.dark... [2]: https://www.cse.unsw.edu.au/~cs9242/15/papers/Blackham_SCRH_11.pdf https://www.cse.unsw.edu.au/~cs9242/15/papers/Blackham_SCRH_...

snvzz 7y ago

>the Windows NT kernel for example (a microkernel design) Windows NT isn't a microkernel design. It does however have some structure to it. Some call it Hybrid kernel, I call it crude layering. It's still better than the spaghetti Linux is. >you couldn't do it Each approach has different tradeoffs. With the microkernel multiserver approach, you get a lot of advantages, such as having a tiny amount of code running in supervisor mode, having strong separation enforced by it, particularly if using the capability model (not to be confused with POSIX capabilities). Possibly formally proven like seL4. It is possible to build a secure system on such a design. It is also possible to build a hard realtime (with proven WCET). It is not possible to do either with a monolith, because of the impossibility of proving the correctness of the monolith inherent to its sheer size and the exponential nature of verification work. In detriment, there's more context switches, which have a cost. But this cost is an order of magnitude smaller on seL4 than Linux, for a solid example. You'd need a severe amount of extra context switches for an actual performance penalty. And seL4 would still have a massive advantage in latency. >but you are just trolling here. No, I am not, and I do not appreciate the accusation. Try and be kind.

asveikau 7y ago
You don't have to explain microkernels to me, I know how they work. You could replicate the advantages I describe of path caching in Linux VFS in a microkernel by having some kind of common VFS server, or perhaps write the VFS layer as a library that filesystems consume. This is because micro vs. monolithic is an orthogonal choice to the design. The fact that it has not chosen your favorite approach on that unrelated axis does not make it bad.
- snvzz 7y ago
  >The fact that it has not chosen your favorite approach on that unrelated axis does not make it bad. It is not possible to implement a general purpose OS on a monolithic architecture. Try as you might you'll always fall short, because it's not possible to do hard realtime on a monolith no matter how much some pretend otherwise (no WCET means no hard realtime. Must have proof of not missing those deadline), nor is it possible to have security (huge TCB, no security. No amount of mitigation can do away with this fundamental problem). And thus, you'll always fall short of general purpose. That's the point I'm making. Linux and all these other systems we use aren't general purpose operating systems. They're just stopgaps. They're due to be replaced. The question isn't if but when and by what exactly.
  - burfog 7y ago
    Well, I guess nothing qualifies then, because you can't have a WCET on commodity hardware. You'd have to have a CPU without any kind of cache (branch history, TLB, etc.) and without any kind of instruction scheduling. You couldn't even have two cores sharing a bus, either on chip or on the motherboard. Due to the above, security is also in question. Spectre and related troubles take care of that. Most people have a very different idea of "general purpose operating systems". It includes Linux. Microkernels have huge problems. Reality disagrees with Andrew S. Tanenbaum. Simplification of components does not come free. Those simple components can have fiendishly complex interactions with each other. Some proven-secure microkernel systems are really insecure because all the buggy code has been shoved into parts that don't count for the security audit. Practical data structure choices become very limited, killing performance. Context switches have always been costly, and the situation has suddenly gotten far worse because we now require Spectre mitigation. Remember also that performance problems are energy use problems. You might be willing to tolerate slowness, but consider battery life and the power fed into huge server farms.
    - snvzz 7y ago
      >Most people have a very different idea of "general purpose operating systems". It includes Linux. A popular misconception is still a misconception. >all the buggy code has been shoved into parts that don't count for the security audit. I hate to repeat myself, but as explained above, at least the microkernel multiserver design has a chance of being secure, because it doesn't run more code than needed in supervisor mode, and isolates components individually. A monolith cannot, because it has an excessively large trusted computer base, which makes cost of proof impractical. >Microkernels have huge problems. Reality disagrees with Andrew S. Tanenbaum. I refer you to the last installment of the Linus-AST debate[0]. >killing performance. I recommend this article[1]. >Well, I guess nothing qualifies then, because you can't have a WCET on commodity hardware. You'd have to have a CPU without any kind of cache (branch history, TLB, etc.) and without any kind of instruction scheduling. You couldn't even have two cores sharing a bus, either on chip or on the motherboard. seL4 has WCET for x86. It simply assumes the worst case for all of this. And it's still a good WCET. I recommend you read the paper[2]. [0]: http://www.cosy.sbg.ac.at/~clausen/PVSE2006/linus-rebuttal.html http://www.cosy.sbg.ac.at/~clausen/PVSE2006/linus-rebuttal.h... [1]: https://web.archive.org/web/20200216184858/https://blog.darknedgy.net/technology/2016/01/01/0/ https://web.archive.org/web/20200216184858/https://blog.dark... [2]: https://www.cse.unsw.edu.au/~cs9242/15/papers/Blackham_SCRH_11.pdf https://www.cse.unsw.edu.au/~cs9242/15/papers/Blackham_SCRH_...