What I've noticed

Here are things I've noticed lately. Some need to be fixed, some are possible improvements, and some are just interesting.

(?) = uncertainty

Append rs_verbose=2 or rs_verbose=3 to a menu option in /boot.cfg, and then reboot. MINIX will crash. It looks like an environment parameter parsing problem.

Shutting down doesn't work. It just restarts.

During installation, the first progress bar for copying files ends with “2” things remaining. Shouldn't it be 0?

GDB needs line-editing to work on the console. It currently only works on virtual terminals.

For some packages, such as sysutils/scanpci, pkgsrc can't download the distribution file archives. It looks like the problem is caused by some of the changes that were used to add MINIX's alternate server locations as the default distfile locations. This needs to change for many packages to work.

The solution most likely involves using one of pkgsrc's existing distfile site variables. The variables might be documented in pkgsrc/docs/pkgsrc.txt (?), but they are also in pkgsrc/mk/fetch.mk (?). It would probably be a good idea to compare NetBSD's settings with MINIX's ones. The correct variable settings might be able to go in /usr/pkg/etc/mk.conf.

By asking on the #minix IRC channel, it turns out that common problem people have with MINIX is following the instructions in docs/UPDATING. In my experience, these are almost always sets of commands that can be run verbatim. In some cases, they involve finding whether or not components are installed and removing them if they are.

I think the instructions can be automated as a set of scripts or “makefiles.” Specific instructions could be run before or after builds of MINIX. Steps that involve checking things could be handled by using feature-testing: carefully checking if things exist, instead of assuming they do. That way, users would no longer have to interact with them.

The down-side is that if a user wants to keep an old feature, they will have to rebuild MINIX more manually. Thankfully, I don't think many users require older features to be kept.

Some alternatives include managing updates like packages or simply installing and configuring all required parts. Simply installing and configuring parts might work, but updated systems would probably accumulate unnecessary parts. Treating updates like packages could work and might be the most elegant solution, however it requires all parts to be tracked in a database of some kind.

Switching from an “unpackaged” system to a “packaged” one might also be tricky, but it might be similar to the ABI update routines. Two interesting side-effects could be that user software package updates could be required by operating system package updates and that all updates could be downloaded and installed using the same package installer program.

Setup could have the following to be saved as .tar.xz's and listed as options:

[x] New system

[ ] Update & Repair

[x] Source code

[x] Default packages

[ ] Pkgsrc: third-party software

Some things that could already be packaged are:

• / as root.txz

• /usr as usr.txz

• /usr/pkg as packages.txz

• Packages, such as Clang and Pkgin, would be installed via chroot and pkgin_cd during installation, if selected

Would it make sense if there were no /home users by default? That would make the setup process simpler and wouldn't lead to questions of why AST and Bin are users. (This would lead to changes in the users MINIX has.)

I'm not against keeping it how it is though. I just think this would make things simpler and give less questions to new users.

Should there be only one filesystem ( /, the root one )?

When is the separation of /, /usr, and /home useful or necessary? The installer currently has an option to update the system by leaving just /home alone. Isn't it possible to do the same on a single filesystem?

Where this could be a problem would be when the filesystem itself needs to be changed. Hopefully this shouldn't be very often, and users have a way to migrate their entire system.

Erasing /root and /usr/local is actually a problem for real users. Would it be possible to use only precisely targeted packaged updates so that the user's things are left alone no matter where they are?

Should the ISO be an installer, a live system, or both?

I'd really appreciate knowing how and where missing functionality should be added. For example, where should POSIX threads be implemented? Should it be in its own server, in a library, in existing servers (which and why?), or in the kernel (technically, there's no good reason for it)? (I don't want an answer to just this question, but to this kind of question in general.)

I don't know if the following ideas have already been thought of.

I've noticed that a seemingly unrelated failure in one part of the system can lead to the whole system slowing down, freezing, or crashing.

Is there a way to prevent these by systematic design? Could the critical parts of the system trust only each other and not other components?

Here's an illustration of what I mean:

• Trusted: Kernel

• Somewhat trusted: RS, VM, VFS, PM, & Sched

• Untrusted: TTY, Inet/lwIP, drivers, & other services

• Sandboxed: Everything else

Could these somewhat trusted parts be run within a single, fixed-quantum task queue while others are run, while untrusted and sandboxed parts would be in multilevel queues?

Could auto-detection be added so that support for additional functionality; such as floppy, CD-ROM, IDE, ACPI, APIC, AHCI, SATA, SMP, and USB support; are loaded when they're needed?

Would it make sense or be possible for devices to automatically have “device nodes” created or removed when they're attached or detached from the computer?

Problem

I don't know much about how VM manages memory currently, so what I'm suggesting might be pointless.

Concept

All memory is treated like a linked-list, and the process list is the root.

Advantages

• VM is stateless

• VM can read the first process list item to find everything

• The first process list item is easy to find (at address 0)

• All process information could be saved similarly

• Memory is like a filesystem

• Any amount of memory can be used

• The only limit is physical memory; everything else is virtual

Disadvantages

• Memory must be traversed to find anything about any process

• Later added data may take longer to reach

Illustration:

0 (address)

		process list item:

		{

			name			kernel
			pid			-1
			text list address	(next free address)
			stack list address	(next free address)
			heap list address	(next free address)
			next process item	(next free address)

		}

after process list item 1 (address)

		text list item:

		{

			start			(next free address)
			length			(determined extent)
			next text address	null

		}

after kernel's code (address)

		stack list item:

		{

			start			(next free address)
			length			(determined extent)
			next stack address	null

		}

after kernel's stack (address)

		heap list item:

		{

			start			(next free address)
			length			(determined extent)
			next heap address	null

		}

after kernel's heap (address)

		process list item:

		{

			name			(...)
			pid			(...)
			text list address	(next free address)
			stack list address	(next free address)
			heap list address	(next free address)
			next process item	(next free address)

		}

...and so on.