Editing DNIX (section)

== ISC's extensions ==
ISC purchased both 5.2 ([[SVR2]] compatible) and 5.3 ([[SVR3]] compatible) versions of DNIX. At the time of purchase, DNIX 5.3 was still undergoing development at [[DIAB]] so DNIX 5.2 was what was deployed. Over time, ISC's engineers incorporated most of their 5.3 kernel's features into 5.2, primarily [[Shared memory (interprocess communication)|shared memory]] and [[inter-process communication|IPC]], so there was some divergence of features between [[DIAB]] and ISC's versions of DNIX. DIAB's 5.3 likely went on to contain more SVR3 features than ISC's 5.2 ended up with. Also, DIAB went on to DNIX 5.4, a [[SVR4]] compatible OS.

At ISC, developers considerably extended their version of DNIX 5.2 (only listed are features involving the [[Kernel (operating system)|kernel]]) based upon both their needs and the general trends of the Unix industry:

* Diskless workstation support. The workstation's kernel file system was removed, and replaced with an X.25-based Ethernet communications stub. The file server's kernel was also extended with a mating component that received the remote requests and handed them to a pool of kernel processes for service, though a standard handler could have been written to do this. (Later in its product lifecycle, ISC deployed standard [[SVR4]]-based Unix servers in place of the DNIX servers. These used [[X.25]] [[STREAMS]] and a custom-written file server program. Despite the less efficient structuring, the raw horsepower of the platforms used made for a much faster server. It is unfortunate that this file server program did not support all of the functionality of the native DNIX server. Tricky things, like [[named pipes]], never worked at all. This was another justification for the named pipe handler process.)
* [[gdb]] watchpoint support using the features of ISC's [[memory management unit|MMU]].
* [[Asynchronous I/O]] to the file system was made real. (Originally it blocked anyway.)  Kernel processes (kprocs, or threads) were used to do this.
* Support for a truss- or [[strace]]-like program. In addition to some repairs to bugs in the standard Unix ''ptrace'' single-stepping mechanism, this required adding a temporary process adoption facility so that the tracer could use the standard single-stepping mechanism on existing processes.
* [[SVR4]] [[Signal (computing)|signal]] mechanism extensions. Primarily for the new ''STOP'' and ''CONT'' signals, but encompassing the new signal control calls as well. Due to ISC's lack of source code for the [[Advanced Debugger|adb]] and sdb debuggers the u-page could not be modified, so the new signals could only be blocked or receive default handling, they could not be caught.
* Support for network [[packet sniffer|sniffing]]. This required extending the [[Ethernet]] driver so that a single event could satisfy more than one I/O request, and conditionally implementing the hardware filtering in software to support [[promiscuous mode]].
* [[Disk mirror]]ing. This was done in the file system and not the device driver, so that slightly (or even completely) different devices could still be mirrored together. Mirroring a small hard disk to the floppy was a popular way to test mirroring as ejecting the floppy was an easy way to induce disk errors.
* 32-bit [[inode]], 30-character filename, [[symbolic link]], and [[sticky bit|sticky]] directory extensions to the file system. Added /dev/zero, /dev/noise, /dev/stdXXX, and /dev/fd/X devices.
* Process group id lists (from [[SVR4]]).
* #! direct script execution.
* Serial port multiplication using ISC's [[Z-80]] based [[VMEbus]] communications boards.
* Movable swap partition.
* Core 'dump' snapshots of running processes. Support for [[fuser (Unix)|fuser]] command.
* Process renice function. Associated timesharing reprioritizer program to implement floating priorities.
* A way to 'mug' a process, instantly depriving it of ''all'' memory resources. Very useful for determining what the current [[working set]] is, as opposed to what is still available to it but not necessarily being used. This was associated with a GUI utility showing the status of all 1024 pages of a process's memory map. (This being the number of memory pages supported by ISC's MMU.)  In use you would 'mug' the target process periodically through its life and then watch to see how much memory was swapped back in. This was useful as ISC's production environment used only a few long-lived processes, controlling their memory utilization and growth was key to maintaining performance.

=== Features that were never added ===
When DNIX development at ISC effectively ceased in 1997, a number of planned OS features were left on the table:

* [[Shared object]]s – There were two dynamically loaded libraries in existence, an encryptor for DNET and the GUI's imaging library, but the facility was never generalized. ISC's machines were characterized by a general lack of [[virtual address]] space, so extensive use of memory-mapped entities would not have been possible.
* [[Lightweight process]]es – The [[Kernel (operating system)|kernel]] already had multiple threads that shared a single MMU context, extending this to user processes should have been straightforward. The [[API]] implications would have been the most difficult part of this.
* [[Access-control list]]s (ACL) – Trivial to implement using an ACL handler mounted over the stock file system.
* Multiple swap partitions – DNIX already used free space on the selected volume for swapping, it would have been easy to give it a list of volumes to try in turn, potentially with associated space limits to keep it from consuming all free space on a volume before moving on to the next one.
* Remote kernel debugging via [[gdb]] – All the pieces were there to do it either through the customary serial port or over Ethernet using the kernel's embedded X.25 link software, but they were never assembled.
* [[68030]] support – ISC's prototypes were never completed. Two processor piggyback plug-in cards were built, but were never used as more than faster 68020's. They were not reliable, nor were they as fast as they could have been due to having to fit into a 68020 socket. The fast context switching ISC MMU would be left disabled (and left out altogether in proposed production units), and the embedded one of the 68030 was to have been used instead, using a derivative of the DS90-20's MMU code. While the ISC MMU was very efficient and supported instant switching among 32 resident processes, it was very limited in addressability. The 68030 MMU would have allowed for much more than 8 MB of virtual space in a process, which was the limit of the ISC MMU. Though this MMU would be slower, the overall faster speed of the 68030 should have more than made up for it, so that a 68030 machine was expected to be in all ways faster, and support much larger processes.