Forum Replies Created
- AuthorPosts
- in reply to: Memory Allocation #3709
> Mill does not have the SeL4 problem of needing to know permissions at thread creation. Because we use a grant model rather than a capability model, you can create a turf with no permissions at all and then add permissions dynamically later by subsequent grants of permission.
I don’t think SeL4 sees this as a problem. If you can grant permissions later, you still need a way of referencing the turf. The point is that even the ability to reference the turf is a privledge in SeL4, which I think is actually quite novel and makes sense. Linux has recently had to “fix” this problem with process handles (using a file descriptor), because process IDs sometimes get reused. Which is similar to the question about:
> the set of Well Known Regions
How does this fit into the graph and not level or flat permission model? This sound to me like exactly what I was asking about, but it is not defined.
- in reply to: Memory Allocation #3707
> arbitrary service graph
This makes alot of sense. While I am not intricately intimate with the SeL4 codebase, this would be a similarity. For example, if you do not share permissions when creating a SeL4 thread it will NEVER be able to communicate or share with its creator (aside from side-channel timing attacks, which is the next big validation target, but requires CPUs to have better concepts of time, and there is a new RISC-V instruction they are recommending)
Do you have to check the memory mappings/permissions are a subset every time you change turfs, or is there some way this is cached with some privledged calls (privledge by the graph, and not levels or flat, as you say)?
- in reply to: Inter-process Communication #3614
> Caller and callee can share an allocation arena set up in advance and used for multiple calls.
You could return a read-only grant to found data, because those grants have byte-granularity.
And a filesystem daemon could also provide shared mmaped files in the direct VM space (instead of process-specific VM space).—hmm that wouldn’t work. How can IPC use the same parameters both when passing by copy and through zero-copy (VM manipulation)?
-
This reply was modified 4 years, 2 months ago by
ShawnL.
-
This reply was modified 4 years, 2 months ago by
- in reply to: Inter-process Communication #3549
> such as a MMU
You still need something to enable de-fragmentation, and that same machinery would give you the ability to implement CoW for fork(), and perhaps sparse maps.
I am talking about having a 32-bit addressing mode on a 60-bit mill, for performance/memory/cache reasons.
- in reply to: Inter-process Communication #3547
Ahh, I guess I answered my question. You want the Mill to support existing code, and quirks are a great way of turning people away, and plenty of existing code needs more address space than 32-bits. And later you could release a Zinc that only support 32-bit addresses in the local address space.
- in reply to: Inter-process Communication #3546
OK, I just watched the whole video. I would love to be part of supporting/developing the C API on top of turfs[1], as I think this is really cool. One question stuck out, which is that you say you have global addresses and the TLB *after* the cache, and then you say you have a local bit. But if the local address space is 60-bits you would have to put a TLB *before* the cache to support local addresses. Why not instead shrink the local address space to something smaller like 32-bits (convenient because applications generally have to support 32-bit arches, so you can just compile apps in 32-bit mode), and then just implicitly fill in a zero top with the thread+turf id, and thus preserve the global address space model, while still supporting the local addressing abstraction?
[1] As you pointed out, the C API is insufficient, because there is no concept of a slice (pointer and length, with constant property) to transfer address space.
- in reply to: Inter-process Communication #3545
Can you compare your ideas behind IPC to the seL4 operating system, which is the first operating system that comes with proofs of correctness (including proofs that the compiler correctly translated the code to assembly!). Awaiting features from CPU vendors, they are also on the cutting edge of doing time-dimension proofs. The feature that I see seems lacking on seL4 is futex(), with all its security coming from the page tables and seL4’s existing memory type system, but otherwise everything both you and seL4 seem to be talking about is properly utilizing the MMU to its full potential.
> However, argument reordering is not done by LLVM, and we have no plans to add it to LLVM any time soon.
But doesn’t conform loop quite a bit like the block arguments that MLIR uses, as a different way to represent PHI nodes? It seems that conform is a sensible way to model branches that have multiple target PHI nodes. (I have programmed LLVM with such PHI nodes, but I understand why MLIR uses argument instead).
- AuthorPosts
