4 ms·

Good points. Indulge me for a minute while I try to formulate what they might say in response: most of the complexity of an OS is device drivers. You're right,

by sounds 12y ago

Good points. Indulge me for a minute while I try to formulate what they might say in response: most of the complexity of an OS is device drivers. You're right, the basics of process isolation, scheduling, and resource allocation are pretty dull. Maybe the UW project makes the move to userspace official? At 1,000,000 packets per second it is more efficient to put the whole network stack in userspace. Assume similar gains can be had for all types of hardware, and shared libraries eliminate the overhead of loading the whole network stack every time you run 'ping'. That's just a 30-second pitch for the idea. Userspace is not new (see: Mach). I think what is changing is the average lifetime of each process. Both desktops and servers are beginning to become a commodity to the point where the old reasons for not using a microkernel are starting to become irrelevant: e.g. message passing cost isn't as much of a problem if the file server runs 'smbd' 99% of the time and that is the only really performance-sensitive application. Likewise for a desktop, except the running process is 'Chrome', or for a tablet running 'dalvikvm'. Really it's a move away from code complexity that wasn't possible before but is becoming possible.

npsimons 12y ago
So are we talking Microkernel here or something else? Sorry to constrain by categorizing, but it's what I do sometimes :) and I am thinking of some OSes (mostly research/academic) that went this way (of no layers between userland and the hardware) that weren't Microkernels, but I can't remember any names right now. I have to admit, part of what keeps my interest in this is that I used to dabble in OSes and I haven't gotten to for quite some time :( EDIT: Exokernel was what I was remembering (I think; https://en.wikipedia.org/wiki/Exokernel https://en.wikipedia.org/wiki/Exokernel). I can see some of the advantages, but as a current maintenance programmer and previous RTLinux hacker, I have to say I have my doubts about giving most programmers direct access to hardware :) That being said, giving programmers (and admins!) easier access to containerization, virtualization, or just intra-process protection in general would be a good idea. As I've said, there are plenty of options right now, but none seem to be well documented or advertised. There was a CACM article a while back that predicted a future in which you had one smartphone, but it had split domains for work and personal apps and data. Interesting stuff, and as you say, finally becoming possible.
- sounds 12y ago
  Now that more knowledgeable people have chimed in, it looks like Arrakis is an exokernel that only needs hardware virtualization to isolate domains.
- nostrademons 12y ago
  The idea behind exokernels isn't that you give "most programmers" direct access to hardware, it's that you give a library writer direct access to hardware, and then programs link in the libraries that are most appropriate for their application. Basically, separate protection from policy & abstraction: the kernel still provides protection, but the library handles all policy & abstraction details. So instead of having your database mimic disk blocks on top of a filesystem, just expose the raw disk blocks to the DB. Instead of having your garbage collector fight the virtual memory system, expose the TLB and physical pages to the language runtime. Instead of requiring that every read() go through the kernel, have the NIC write directly into application buffers. The big change that makes this desirable now but undesirable before is that machines are becoming increasingly single-tasked. When everybody owned a desktop and had a dozen programs on it, you needed to write an abstraction that could support all of those programs. When everybody just runs a web browser that connects up to a web server in the cloud which connects up to appservers and databases running on separate machines, each machine only needs to support one type of application. So let that app link in the abstractions it needs and only those abstractions, ensure that existing daemons don't trample over each other, and have the kernel get out of the way.
  - Dewie 12y ago
    > So instead of having your database mimic disk blocks on top of a filesystem, just expose the raw disk blocks to the DB. Instead of having your garbage collector fight the virtual memory system, expose the TLB and physical pages to the language runtime. Instead of requiring that every read() go through the kernel, have the NIC write directly into application buffers. This sounds great. Do you know of any literature/writings on these kind of things for programming languages, specifically? For example the thing you mentioned about language runtimes.

by sounds 12y ago

npsimons 12y ago

So are we talking Microkernel here or something else? Sorry to constrain by categorizing, but it's what I do sometimes :) and I am thinking of some OSes (mostly research/academic) that went this way (of no layers between userland and the hardware) that weren't Microkernels, but I can't remember any names right now. I have to admit, part of what keeps my interest in this is that I used to dabble in OSes and I haven't gotten to for quite some time :( EDIT: Exokernel was what I was remembering (I think; https://en.wikipedia.org/wiki/Exokernel https://en.wikipedia.org/wiki/Exokernel). I can see some of the advantages, but as a current maintenance programmer and previous RTLinux hacker, I have to say I have my doubts about giving most programmers direct access to hardware :) That being said, giving programmers (and admins!) easier access to containerization, virtualization, or just intra-process protection in general would be a good idea. As I've said, there are plenty of options right now, but none seem to be well documented or advertised. There was a CACM article a while back that predicted a future in which you had one smartphone, but it had split domains for work and personal apps and data. Interesting stuff, and as you say, finally becoming possible.

sounds 12y ago
Now that more knowledgeable people have chimed in, it looks like Arrakis is an exokernel that only needs hardware virtualization to isolate domains.
nostrademons 12y ago
The idea behind exokernels isn't that you give "most programmers" direct access to hardware, it's that you give a library writer direct access to hardware, and then programs link in the libraries that are most appropriate for their application. Basically, separate protection from policy & abstraction: the kernel still provides protection, but the library handles all policy & abstraction details. So instead of having your database mimic disk blocks on top of a filesystem, just expose the raw disk blocks to the DB. Instead of having your garbage collector fight the virtual memory system, expose the TLB and physical pages to the language runtime. Instead of requiring that every read() go through the kernel, have the NIC write directly into application buffers. The big change that makes this desirable now but undesirable before is that machines are becoming increasingly single-tasked. When everybody owned a desktop and had a dozen programs on it, you needed to write an abstraction that could support all of those programs. When everybody just runs a web browser that connects up to a web server in the cloud which connects up to appservers and databases running on separate machines, each machine only needs to support one type of application. So let that app link in the abstractions it needs and only those abstractions, ensure that existing daemons don't trample over each other, and have the kernel get out of the way.
- Dewie 12y ago
  > So instead of having your database mimic disk blocks on top of a filesystem, just expose the raw disk blocks to the DB. Instead of having your garbage collector fight the virtual memory system, expose the TLB and physical pages to the language runtime. Instead of requiring that every read() go through the kernel, have the NIC write directly into application buffers. This sounds great. Do you know of any literature/writings on these kind of things for programming languages, specifically? For example the thing you mentioned about language runtimes.