libcodr7 VS illumos-gate

I have a fairly comprehensible left leaning rb tree implementation that I've been porting along my travels.

I keep it around for situations where a binary searched array isn't doable or good enough, but I still want ordered set functionality that isn't in the stdlib.

https://github.com/codr7/whirlog/blob/main/rb.lisp

https://github.com/codr7/libcodr7/blob/master/source/codr7/t...

From my experience, the only kind of linked list that still sometimes makes sense is the embedded one.

https://github.com/codr7/libcodr7/blob/master/source/codr7/l...

The Solaris documentation says that this is not allowed:

https://docs.oracle.com/cd/E88353_01/html/E72487/link-8.html

If it ever were allowed, it was a bug. While the VFS is flexible enough to allow for it, the filesystem driver should not to protect itself from leaking orphan subtrees. There is no code in ZFS as far as I know to determine whether there is an orphaned subtree on an unlink and adding it would be very inefficient, as you would need to do a traversal on every unlink while having some way to detect and avoid cycles.

The illumos man page is less clear:

https://illumos.org/man/8/link

However, the ZFS driver makes it very clear that this is not allowed:

https://github.com/illumos/illumos-gate/blob/master/usr/src/...

The comment states that this is disallowed under POSIX.

It’s still going, in the form of Illumos: https://illumos.org/

DTrace and eBPF are "not so different" in the sense that dtrace programs / hooks are also a form of low-level code / instruction set that the kernel (dtrace driver) validates at load. It's an "internal" artifact of dtrace though, https://github.com/illumos/illumos-gate/blob/master/usr/src/... and to my knowledge, nothing like a clang/gcc "dtrace target" exists to translate more-or-less arbitrary higher-level language "to low-level dtrace".

The additional flexibility eBPF gets from this is amazing really. While dtrace is a more-targeted (and for its intended usecases, in some situations still superior to eBPF) but also less-general tool.

(citrus vs. stone fruit ...)

We can see it is called sched. Why sched? This article talked about the historic role of PID 0 in process swapping. Process swapping is a scheduling problem (like a lot of problems in software). This is why swappers are traditionally called medium-term or memory schedulers. Illumos generally gives most groupings of kernel worker threads their own processes with their own PIDs, but one, called "sched", remains in PID 0, and its responsibility? Process swapping:

https://github.com/illumos/illumos-gate/blob/579c23696ac6891...

The Wikipedia article has now been hastily edited, and replaces a claim that was true only of certain Unixes other than Linux with a claim true only of certain Unixes including Linux. Is this an improvement?

It may become a footnote on Linux, but Linux isn't the only system out there -- and DTrace remains alive and well in many systems (not least in its reference implementation in illumos[0]).

[0] https://github.com/illumos/illumos-gate

Nobody's paid to have it pass Open Group Unix Branding certification tests

https://www.opengroup.org/openbrand/register/

so it can't use the UNIX™ trade mark.

But it's got the AT&T Unix kernel & userland sources contained in it.

PDP-11 Unix System III: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/ut...

IllumOS: https://github.com/illumos/illumos-gate/blob/b8169dedfa435c0...

> it seems like this bug might actually date back to the very beginning of ZFS with Sun

Looks like you might be right about that. The oldest commit referenced in the fix [0] was from 2006[1], which was just months after Sun released ZFS.

[0] https://github.com/openzfs/zfs/pull/15571

[1] https://github.com/illumos/illumos-gate/commit/c543ec060d