To be honest - I don't speak much C++. If doing what you said is more idiomatic, that's fine so long as it builds. :-)

The problem came when building with GNU C++ 8.3 (Debian 'buster').

(That's assuming someone's going to merge the pull request; the repo seems fairly dead at this point, sadly.)

From the website you can find the link to the Minix Google Group; the most recent thread in that deals with this topic. Link: https://groups.google.com/u/1/g/minix3/c/nUG1NwxXXkg

As Jim said, please close this issue. :-)

On the master branch I receive a build error running on Ubuntu 18.04 and GCC. Command: ./build.sh -m i386 -U build After 38.000 new objects or so I receive this message:

create utils/cmdline/base_command.d

CC=/media/kunz/D1/minix/obj/tooldir.Linux-4.15.0-122-generic-x86_64/bin/i586-elf32-minix-clang++ /media/kunz/D1/minix/obj/tooldir.Linux-4.15.0-122-generic-x86_64/bin/nbmkdep -f cmdline/base_command.d.tmp -- --sysroot=/media/kunz/D1/minix/obj/destdir.i386 -DHAVE_CONFIG_H -DKYUA_CONFDIR="/etc/kyua" -DKYUA_DOCDIR="/usr/share/doc/reference/ref1/kyua/kyua-cli" -DKYUA_EXAMPLESDIR="/usr/share/examples/kyua-cli" -DKYUA_MISCDIR="/usr/share/kyua-cli/misc" -DKYUA_STOREDIR="/usr/share/kyua-cli/store" -DKYUA_TESTERSDIR="/usr/libexec" -DKYUA_TESTSDIR="/usr/tests" -I/media/kunz/D1/minix/external/bsd/kyua-cli -I/media/kunz/D1/minix/external/bsd/kyua-cli/lib -I/media/kunz/D1/minix/external/bsd/kyua-cli/dist /media/kunz/D1/minix/external/bsd/kyua-cli/dist/utils/cmdline/base_command.cpp && mv cmdline/base_command.d.tmp cmdline/base_command.d nbmkdep: unable to write to file cmdline/base_command.d.tmp: No such file or directory

*** Failed target: cmdline/base_command.d

• end of quote -

After this there is more text on probably dependent errors. Looks like a false reference maybe in the script. Is there a current compile or build description somewhere? In case I'm doing something wrong.

What makes you believe that in line 13 anything larger than the size of int is copied into the long long value?

Done the Gordonic solution? ;) Well, we had no choice. I have no idea how a scheduling strategy looks like on a multi-core process deployment. Can you talk a little what you have implemented here? I'm also shocked to see the project has about 80,000 objects in the repository.

Hi all.

First of all I want to apologize for the radio silence for the past year and a half. This pull request was created while I was working on my Master's thesis. At the time I had to fix the SMP support in Minix in order to get started with my thesis and I thought others could benefit from it too, hence this PR. I have to admit that this PR was not really on top of my priority list while I was completing my thesis and later, for personal reasons, I haven't really got time to get back into it.

Second, around June 25th 2019, I changed my email address in my Github account. To avoid loosing all my contributions of the past 7 years or so on my profile I decided to update the email address of all my commits in my repos (which also requires a force push). Something obviously went wrong with my fork of Minix because now this PR wants to merge more than 2200 commits (some of them are not even mine or related to the fixes) with 5000 files changed !! Originally the PR was much lighter, only a handful of files were changed and the changes were simple (see original description of the fixes). Lucky I kept a backup of the repo before the email change + force push. I'll try to restore it and hopefully this will fix this mess.

A few more comments: @boricj : At the time I was fixing SMP while adding the changes for my thesis as well. Hence my version of the code was different than that of this PR. Tests were passing and the system seemed to be stable, however I do agree that more testing on this particular PR/set of changes would not hurt. Regarding scalability I remember having some issues with daemons (VFS, PM, ...) running exclusively on CPU 0. I did change this behaviour in this PR however.

@KSE3 : I would love to help to get this merged. Regarding synchronization, I did not have to change anything, the Big Kernel Lock is still there and doing its job properly.

I see this pull-request takes over the functions of a repository branch and even staff has taken up effort to contribute a lot of work to it. I would wish they could make a nail to it and decide to open a branch "3.4-NT" or so and start collecting the various input that was made to create a usable and modernised version of this operating system. Thanks!

As for multi-coreing, is there any danger arising in synchronisation aspects of the OS through this innovation which hasn't been dealt with multi-processing? I don't think so for now, but are there any objections?

It seems pull request 301 solves this issue? Can anyone confirm?

• https://github.com/Stichting-MINIX-Research-Foundation/minix/pull/301

Thanks now it works :)

I've tested debian only. Yes it does solve the issue

Adding "zero" into /etc/swapspace.conf works. I'm using 1.14 on debian (10) buster. kernel 5.8, and kernel 5.7 failed to create swap files for some reason. Ubuntu seems also affected, can be a kernel bug.

Ubuntu bug report, not sure what is causing it.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1894910

Can we have an option to use fallocate vs dd?