*BSD Geneology and Future

[hanzer]

Inspired by the thread: "Tor-0.2.5.12 can crash OpenBSD-5.7-stable"

I can see that DragonFlyBSD is a fork of FreeBSD 4.8. and OpenBSD was forked from NetBSD in late 1995. But that doesn't help much. The Wikipedia entry for Unix has this diagram (below) but it doesn't have adequate resolution[1] into the BSD subspecies (to help with my speculative thinking).

[1]: Information resolution. A higher visual resolution file is hyper-linked to the image.

Evolution of Unix and Unix-like systems

{A cut to the point}:

1. I'm thinking about how some of the DragonFlyBSD capabilities and features might be useful to OpenBSD users, developers and engineers.
   
2. I'm trying to get a probable architectural gist of how different the OpenBSD and DragonFlyBSD kernels are from each other, with an eye on engineering concerns.
   
3. And I wonder if it would make sense, theoretically, if a new generation of OpenBSD had some of (or all) the Dragonfly developer-engineer-operator tools/features and some of (or all) the process-cluster capabilities/possibilities (including HammerFS if it makes sense).

...just for speculative fun (but good traction with reality). <- That reminds me of a joke:

The optimist says, “The glass is half full”.
The pessimist says, “The glass is half empty”.
The engineer says, “The glass is twice as big as it needs to be”.

[ibara]

Originally Posted by hanzer

I'm thinking about how some of the DragonFlyBSD capabilities and features might be useful to OpenBSD users, developers and engineers.

Which ones? Why? Each would likely require rather invasive porting.

Originally Posted by hanzer

I'm trying to get a probable architectural gist of how different the OpenBSD and DragonFlyBSD kernels are from each other, with an eye on engineering concerns.

To use your metaphor, their closest shared relative is 386BSD/4.4BSD Lite-2. Of course, that belies the code sharing between all the projects. But 1994-1995 is the last time these two OSes had shared architectural work, and that came from the Jolitzes and UCB. 20 years later...

Originally Posted by hanzer

And I wonder if it would make sense, theoretically, if a new generation of OpenBSD had some of (or all) the Dragonfly developer-engineer-operator tools/features and some of (or all) the process-cluster capabilities/possibilities (including HammerFS if it makes sense).

Preliminary HAMMER2 work is a GSoC project for OpenBSD this year. Note that the entire project will only yield preliminary results. Much much more work will need to be done to have the full HAMMER2 file system.

Originally Posted by hanzer

The engineer says, “The glass is twice as big as it needs to be”.

Not any engineer at RPI if my department has anything to say about it!

[hanzer]

Originally Posted by ibara

Which ones?

I quickly grabbed a few blurbs of text from Wikipedia and the Dragonfly Features page:

In DragonFly, each CPU has its own thread scheduler. Upon creation, threads are assigned to processors and are never preemptively switched from one processor to another

PROCESS CHECKPOINTING
Processes under DragonFly may be "checkpointed" or suspended to disk at any time. They may later be resumed on the originating system, or another system by "thawing" them.

Application snapshots
DragonFly BSD supports Amiga-style resident applications feature: it takes a snapshot of a large, dynamically linked program's virtual memory space after loading, allowing future instances of the program to start much more quickly than it otherwise would have.

Originally Posted by ibara

Why?

I've been thinking about a light-weight cluster architecture. 5.7 system freeze - reproducible (post #6)

VKERNEL might also be useful, and/or maybe D-Trace (though, I haven't really thought about the implications). Could be very helpful when there are problems. Tor-0.2.5.12 can crash OpenBSD-5.7-stable (post #3)

Not only are there decades of kernel API differences to worry about, there hasn't been any effort to run the Dragonfly code on non-x86 platforms, which are important to OpenBSD. There lies bugs, and it's a response that Theo's given in the past when questioned about bringing code over from Dragonfly. There's a fundamental difference in culture here, Matthew Dillon's perspective is that supporting one platform leads to a faster/simpler Dragonfly, whereas many OpenBSD developers would say that getting code to run on more platforms benefits the code.

The features I'd like the most in OpenBSD are filesystem rollbacks (undeletion) and a less biglocked kernel. My remaining nits are mostly ports-related, which thankfully I'm smart enough to work on, though I could probably stand to be a bit more patient and focused... oh, and it would be nice for my name to not be in scare quotes when it gets mentioned in commit messages in the future.

HAMMER2 would be nice. It seems like there's a lot that could go wrong even in the process of obtaining preliminary support. Good luck and props to Joris Giovannangeli for taking on such a daunting project.

On the subject of the glass, please don't make it smaller. I don't want to spill liquid everywhere.

[ibara]

Originally Posted by hanzer

I've been thinking about a light-weight cluster architecture. 5.7 system freeze - reproducible (post #6)

VKERNEL might also be useful, and/or maybe D-Trace (though, I haven't really thought about the implications). Could be very helpful when there are problems. Tor-0.2.5.12 can crash OpenBSD-5.7-stable (post #3)

Asking why is supposed to be a yield to thinking about trade-offs.