IRC channel logs

<theruran>that's a bummer

<safinaskar2>theruran: if i remember correctly, i gave you a link to book on pure type systems, right?

<oriansj>theruran: in the short term yes, but when we solve the posix bootstrap problem; it will not be as much of an issue. Also anyone who has written exokernels know supporting I/O directly in an application is a bitch.

<oriansj>trying to handle multiprocess I/O contention in user space ugh

<oriansj>atleast minux and hurd got it right, one trusted process for all I/O

<xentrac>I've never written an exokernel but I don't understand why supporting I/O directly in an application is any different from supporting memory access directly in an application

<xentrac>I mean assuming you have an iommu obviously

<oriansj>xentrac: ask yourself this; imagine every process is able to control the MMU

<oriansj>or the IOMMU in your specific case

<oriansj>that is what an exokernel assumes by default

<xentrac>the exokernel doesn't let every process, or indeed any process, control the MMU; why would it do so with the IOMMU?

<xentrac>I mean as far as I know. Engler never released the code and maybe there was some implementation that did?

<oriansj>xentrac: if the kernel doesn't provide memory management, applications must; which requires access to control the MMU or just a massive flat memory space for all applications

<xentrac>that is of course true, but I don't think that was the approach the exokernel took

<xentrac>seL4 and other recent variants of L4 do delegate memory management to user processes but still intermediate the actual MMU frobbing with kernel calls

<xentrac>even if you do frob the MMU in *a* non-kernel process, though, you wouldn't need to do it in *every* non-kernel process

<theruran>could boot into this .. https://github.com/vygr/ChrysaLisp (:

*vagrantc taunts janneke with the mes readdir bug

IRC channel logs

2019-12-01.log