3 ms·

Still no unified buffer cache. :-( The lack of coherence and memory reuse between mmap(2) and read(2) is my single biggest beef with OpenBSD right now. It's a g

Still no unified buffer cache. :-( The lack of coherence and memory reuse between mmap(2) and read(2) is my single biggest beef with OpenBSD right now. It's a great system in terms of robustness, documentation, and philosophical unification. It's a shame its kernel still thinks Ronald Reagan is president.

_wldu 8y ago
That's a feature.
- quotemstr 8y ago
  Is it?
DblPlusUngood 8y ago
What coherence is lacking? OpenBSD supports msync(2), which is the only POSIX mechanism I know of for ensuring coherency between read(2) and shared file mappings. Otherwise relying on unspecified behavior sounds dangerous.
- quotemstr 8y ago
  Oh, come on. Every other system in common use is fully coherent. POSIX allowing OpenBSD's behavior doesn't make that behavior a good idea or a quality implementation.
  - DblPlusUngood 8y ago
    OpenBSD's choice is arguably reasonable, given their prioritization of security, since it reduces opportunities for user programs to corrupt kernel memory. What is the problem with OpenBSD's plan for coherency? Why is the burden of explicitly calling msync(2) too much?
    - quotemstr 8y ago
      > reduces opportunities for user programs to corrupt kernel memory I don't see how it could. Kernel data structures don't go on pagecache pages. > OpenBSD's choice is arguably reasonable At a human level, the OpenBSD people have spent way too much time coming up with rationalizations for their obsolete VM design to back down now. Whether OpenBSD's VM subsystem is good or not, their pride will force them to keep claiming that it's good, practically forever.
      - DblPlusUngood 8y ago
        > I don't see how it could. Kernel data structures don't go on pagecache pages. Kernel data structures could end up on a pagecache page: all it takes is a reference counting bug and the page could be reallocated in the kernel heap, which is directly mapped by user space. Keeping user-mapped pages and pagecache pages distinct makes this less likely. I am otherwise not convinced that there is an actual problem with OpenBSD's coherency plan.

_wldu 8y ago

That's a feature.

quotemstr 8y ago
Is it?

DblPlusUngood 8y ago

What coherence is lacking? OpenBSD supports msync(2), which is the only POSIX mechanism I know of for ensuring coherency between read(2) and shared file mappings. Otherwise relying on unspecified behavior sounds dangerous.

quotemstr 8y ago
Oh, come on. Every other system in common use is fully coherent. POSIX allowing OpenBSD's behavior doesn't make that behavior a good idea or a quality implementation.
- DblPlusUngood 8y ago
  OpenBSD's choice is arguably reasonable, given their prioritization of security, since it reduces opportunities for user programs to corrupt kernel memory. What is the problem with OpenBSD's plan for coherency? Why is the burden of explicitly calling msync(2) too much?
  - quotemstr 8y ago
    > reduces opportunities for user programs to corrupt kernel memory I don't see how it could. Kernel data structures don't go on pagecache pages. > OpenBSD's choice is arguably reasonable At a human level, the OpenBSD people have spent way too much time coming up with rationalizations for their obsolete VM design to back down now. Whether OpenBSD's VM subsystem is good or not, their pride will force them to keep claiming that it's good, practically forever.
    - DblPlusUngood 8y ago
      > I don't see how it could. Kernel data structures don't go on pagecache pages. Kernel data structures could end up on a pagecache page: all it takes is a reference counting bug and the page could be reallocated in the kernel heap, which is directly mapped by user space. Keeping user-mapped pages and pagecache pages distinct makes this less likely. I am otherwise not convinced that there is an actual problem with OpenBSD's coherency plan.