markjdb

It means that there are two incoherent caches, not that they aren't shared.

Except it may or may not be a only little bit of friction, depending on the breakage, and it is not short-term if it happens regularly.

We are hoping have something similar in the next freebsd release, FWIW.

It's both. There's a lot of prose questioning the intent and competency of FreeBSD developers. The addendum for instance smarmily suggests that the PTI patch had no review at all when it certainly did and the referenced post even contains a link to that review.

1) So why doesn't Taiwan have a seat at the UN?

2) That just indicates that the PRC will continue to exert soft power over Taiwan instead of something more overt.

And Taiwan isn't even one of China's top ten trading partners. So who has more power over the other?

The passport thing doesn't mean anything in and of itself. That's not the point.

1) The PRC exerts indirect control over Taiwan's economy by pressuring its trading partners, so the distinction is academic.

2) That's a historic stance and not one claimed by most Taiwanese people today. Meanwhile, PRC passports devote a page to each province of China, including a page for Taiwan.

What are the "other reasons"?

No, various kernel entry points have been modified to be able to handle 64-bit inode numbers. UFS itself still uses 32-bit inode numbers.

Ok, so that's tighter than what I said, but my point still stands.

> So yes, if you pledge(2) a shell. It can call exec, but directly it can't call socket/connect(2), and the reduction of kernel attack surface is still significant.

Why is that significant if I can fork and exec nc(1)?

> The names of the promises are obvious and their intention is clear. There are subsets of POSIX.

That's true, but not really the whole truth. Take "dns", for instance. It enables a number of system calls needed to perform DNS resolution. But as far as I understand, those system calls (sendto(2) for example) can then be used arbitrarily. So "dns" actually permits more than the name implies.

On the other hand, when a program is running in capability mode, we know exactly what is permitted and what isn't.

> Capsicum has no solution for this, and as such these programs cannot be sandboxed on FreeBSD.

... they can't be sandboxed on OpenBSD either. pledge("proc exec") doesn't give you a sandbox.

The main purpose of CTF is to provide a succinct representation of the graph of C types used in a program. It's generated from DWARF; anything encoded in the CTF section can also be found in DWARF info. CTF has nothing to do with "embedding source code" and isn't useful for stack unwinding or symbol resolution.

You could argue that a system written in a language that permits such errors is not well-thought out. The terms you're using are not well-defined, so it's easy to disagree endlessly without arriving at a useful insight.

You could say that about most bugs...

FreeBSD doesn't have a per-thread cache, but does similarly use a generation number to allow operations to detect stale state upon reacquiring the vm map lock. I don't see why it isn't prone to the same kinds of bugs.

Regarding 3), I suspect that the optimization is rather important for page fault scalability when the process has many threads. You would traditionally synchronize access to the VMA tree using some sort of reader-writer lock, but scalable read locks impose a higher cost to writers. It's easy to believe that splay trees wouldn't help and might hurt in this case, as lookups may modify the tree structure and thus can require more synchronization than a read lock.

Calling this a micro-optimization is thus misleading; rather, it probably helps quite a lot in some particular workloads and has a negligible impact on others.

That patch set does not implement transparent creation of 1GB mappings. It also contains dubious things like this, which make me think the branch was a WIP: https://github.com/Seb-LineRate/freebsd/commit/66a8d3474d410...

The only mailing list thread I see regarding this is here, and it doesn't seem particularly underhanded to me: https://lists.freebsd.org/pipermail/freebsd-hackers/2014-Nov...

Please be aware that the article describes a problem with a specific implementation of THP. Other operating systems implement it differently and don't suffer from the same caveats (though any implementation will of course have its own disadvantages, since THP support requires making various tradeoffs and policy decisions). FreeBSD's implementation (based on [1]) is more conservative and works by opportunistically reserving physically contiguous ranges of memory in a way that allows THP promotion if the application (or kernel) actually makes use of all the pages backed by the large mapping. It's tied in to the page allocator in a way that avoids the "leaks" described in the article, and doesn't make use of expensive scans. Moreover, the reservation system enables other optimizations in the memory management subsystem.

[1] https://www.cs.rice.edu/~druschel/publications/superpages.pd...

> But why FreeBSD over Linux? Honestly it all seems like a waste of time. Linux is already the dominant free OS.

Linux isn't an OS, it's a kernel. There are hundreds of distributions that package Linux and make an OS out of it. You don't think that all that duplication of effort is an even larger waste of time?

Who cares if FreeBSD isn't as relevant. Monocultures suck. There's lots to like and lots to dislike in Linux, and I'm happy that we have other working systems from which to draw lessons and inspiration.

I'm a committer that works for such a commercial outfit, and I certainly don't get to work on FreeBSD full time (though I do work _with_ FreeBSD full time). Most of my contributions still come out of my spare time. I believe that's true for many others as well.

+1

Another FreeBSD developer here. I pay for an LWN subscription to help keep on top of what's happening in Linux and to support the high-quality coverage.

The frequency at which it happens to you is still interesting information, isn't it?

> - DTrace (although not mature enough IMHO)

Can you be more specific about that comment?

Clang has been the default compiler for a while now, and many ports either work just fine or have been patched to work properly with clang. Ports that really need to use gcc (those depending on OpenMP perhaps) can still depend one of the gcc ports.

> all valid C programs will still compile, though not necessarily C++ ones

I don't think that's true:

    struct foo {
        int a;
        int b;
    };

    char arr[sizeof(struct foo) == sizeof(int) ? -1 : 1];