minoca / os

Minoca operating system

Minoca OS

Minoca OS is a general purpose operating system written from scratch. It aims to be lean, maintainable, modular, and compatible with existing software. It features a POSIX-like interface towards application software, and a growing suite of popular packages already built and ready to go. On the backend, it contains a powerful driver model between device drivers and the kernel. The driver model enables drivers to be written in a forward compatible manner, so that kernel level components can be upgraded without necessarily requiring a recompilation of all device drivers.

Minoca OS is event driven, preemptible, SMP ready, and network capable. It currently runs on x86 PCs and a range of ARM boards.

Screenshots

Getting Started

If you're just looking to try out Minoca OS, head over to our download page to grab the latest stable images. The rest of this page describes how to use this repository to build your own custom image of Minoca OS.

Building Minoca OS

The paragraphs below will get you from a fresh clone to a built image.

Environment

The Minoca OS build environment is keyed off of a few environment variables you'll need to set in order to orient the build system:

• SRCROOT - Contains the absolute path to the base source directory. This respository is expected to be in a directory called os inside SRCROOT. If the third-party or tools repositories are present, they should be in directories called third-party and tools respectively underneath SRCROOT. For example, if you had checked out this repository into ~/src/os, then in your shell you'd run export SRCROOT=~/src.
• ARCH - Contains the architecture to build Minoca OS for (aka the target architecture). Valid values are armv6, armv7, and x86.
• VARIANT - Contains the architecture variant, if any. Leave this unset most of the time. Currently the only valid value is q for the x86 architecture, which builds for the Intel Quark.
• DEBUG - Describes whether to build Minoca OS for debugging or release. Valid values are dbg for debug or rel for release. We always build dbg.
• PATH - You'll need to have $SRCROOT/$ARCH$VARIANT$DEBUG/tools/bin in your path to build successfully.

Prerequisites

To build Minoca OS you'll need a Minoca-specific toolchain for the particular architecture you're building. Prebuilt toolchains can be found here. If you want to build the toolchain from sources, you'll need to check out the third-party repository and run "make tools" in there.

Note: If you want to build your own toolchain on Windows, you may find the tools repository helpful, as it contains a native MinGW compiler, make, and other tools needed to bootstrap a toolchain on Windows.

Build

Run make to build the OS for the particular architecture you've supplied. Parallel make is supported. The final output of the build will be several .img files located in $SRCROOT/$ARCH$VARIANT$DEBUG/bin/*.img. For example, the PC image is usually located at $SRCROOT/x86dbg/bin/pc.img. This is a raw hard disk file that can be applied directly to a hard drive or USB stick to boot Minoca OS. The image install.img is a generic installation archive that the msetup tool can use to create new Minoca OS installations on target disks or partitions.

Object files are generated in $SRCROOT/$ARCH$VARIANT$DEBUG/obj/os. You can run make clean, or simply delete this directory, to cause the os repository to completely rebuild. Alternatively, you can run make wipe to delete all generated files, including the third-party tools you built or downloaded. Running make wipe simply deletes $SRCROOT/$ARCH$VARIANT$DEBUG/. We usually stick to make clean since make wipe requires a complete rebuild of the toolchain.

A note for macOS users: We've managed to build successfully using both GCC from XCode 8 (really clang) and Homebrew GCC, both using the 10.12 SDK. Some users have reported that they need to export SDKROOT=$(xcrun --show-sdk-path) to build properly.

Running

To boot your built images, you can write the appropriate image for the platform you're trying to boot to a USB flash drive or hard disk. On Windows, you can use the Win32DiskImager tool (included in the tools repository under win32/Win32DiskImager). You can also use the msetup tool to build custom images. If you use the msetup tool to install Minoca OS onto a partition of a disk containing other partitions that you care about (such as on the same machine you're building from), we highly recommend making a complete backup of your disk. Minoca OS is still new, and we wouldn't want a bad bug to wipe out all your data.

If you're building Minoca OS on Windows and have downloaded the tools repository, several shortcuts have been set up to allow you to quickly run a Qemu instance with the images you've just built. Make sure you fired up the development environment with the setenv.cmd script. Type run, then dx to fire up an x86 Qemu instance of pc.img with a kernel debugger attached. We use this internally for faster development. If building for ARM, it's runarm and da.

Nickel Tour

Below is a brief orientation of a few of the directories in the repository. Check the Makefile in each directory for a more detailed description of what that directory contains.

• apps - User mode applications and libraries
  • ck - Chalk, an embeddable scripting language
  • debug - Debugger application
  • libc - The Minoca OS C Library
  • osbase - The Minoca kernel API library
  • setup - The msetup build tool
  • swiss - POSIX tools in a box
• boot - Executables used during system boot
  • mbr - The Master Boot Record
  • fatboot - The Volume Boot Record for FAT file systems
  • bootman - The Minoca Boot Manager
  • loader - The Minoca OS loader
  • lib - Libraries shared across multiple boot executables
• drivers - Device drivers
  • acpi - ACPI platform driver, with AML interpreter
  • fat - FAT file system driver
  • gpio - GPIO core library and SoC drivers
  • net - Networking support
    • ethernet - Wired ethernet controller drivers
    • net80211 - Core 802.11 support
    • netcore - Core networking support (TCP, UDP, IP, ARP, etc)
    • wireless - 802.11 wireless controller drivers
  • pci - PCI support
  • sd - SD/MMC support
  • spb - Serial Peripheral Bus drivers (I2C, SPI)
  • special - Special devices (/dev/null, full, zero)
  • usb - USB support
    • ehci - EHCI host controller support
    • usbcomp - USB composite device support
    • usbhid - USB HID support
    • usbhub - USB hub support
    • usbkbd - USB keyboard support
    • usbmass - USB mass storage support
    • usbmouse - USB mouse support
  • input - User input drivers
  • videocon - Video terminal console driver
• images - Recipes to create the final images for each supported platform
• include - Public header files
• kernel - The Minoca OS kernel
  • ke - High level executive functions
  • mm - Memory management
  • io - Input/Output subsystem
  • kd - Kernel debug support
  • hl - Low level hardware layer support
  • ob - Object management
  • ps - Process and thread management
  • sp - System profiler support
• lib - Common libraries used throughout boot, kernel, and user mode.
  • basevid - Library for drawing text on a framebuffer
  • fatlib - FAT file system library
  • im - ELF/PE image library
  • partlib - Partition library
  • rtl - General runtime library (printf, date/time, memcpy, etc)
  • termlib - Terminal support library
• tasks - Internal automation configuration
• uefi - Minimal UEFI implementation for platforms supported by Minoca OS.
  • core - Platform-agnostic UEFI firmware core
  • dev - UEFI device libraries
  • plat - Recipes and code for specific platforms
    • beagbone - BeagleBone Black firmware
    • bios - UEFI over BIOS firmware
    • integcp - Integrator/CP firmware (for ARM Qemu)
    • panda - TI PandaBoard firmware
    • rpi - Raspberry Pi 1 firmware
    • rpi2 - Raspberry Pi 2 and 3 firmware
    • veyron - Asus C201 Chromebook firmware
  • tools - Tools used in building final firmware images

Contributing

Submissions are welcome! See our CONTRIBUTING.md page for details, or our WISHLIST page for suggestions. Bugs can be reported here on Github.

License

Minoca OS is licensed to the public under the terms of the GNU General Public License, version 3. Alternate licensing options are available. Contact [email protected] if your company is interested in licensing Minoca OS. For complete licensing information, see the LICENSE file in this repository.

Contact

• Email: [email protected]
  • Contact [email protected] for security related issues.
  • Contact [email protected] for private or business inquries.
• Website: http://www.minocacorp.com/
• Github: https://github.com/minoca
• Gitlab: https://gitlab.com/minoca
• IRC: ircs://irc.oftc.net:6697/minoca-os

os's Issues

Minoca Debugger window does not appear.

This one came in from Ilya via email:

The debugger hardly ever starts on windows when using the .bat file provided in the Minoca OS Starter Pack, the only time it ever started was on the first ever time i started the OS from the bat file. It doesn't appear even when the exe is launched

We save the last debugger location and size in a preferences file so that it returns to the same spot the next time you launch it. There appears to be a corner case where the location is saved as (0,0) and the (height,width) is saved as (0,0).

The work around is to delete C:\Users\YourUserName\AppData\Roaming\Minoca\DebugUI\prefs.

The debugger already tries to guard against saving minimized or maximize state, as that doesn't work well either. The appropriate fix at this point is to refuse to save the zero state to the prefs file.

Is it possible for MIPS support?

Static analysis issues from Cedric

Cedric Picard posted this analysis on the mailing list.

==========
Bug report

Version 0cb08c9

Excluded from the scope

• Debug functions

• Test apps

Bugs found

fprintf format wrong number of parameters

• apps/efiboot/efiboot.c:554

This can become a vulnerbility issue because it ends up leaking a pointer to
the stack which can be used to manipulate precise data when exploiting a
memory corruption vulnerability.

As far as I can tell Minoca doesn't have ASLR so this is less of an issue as
that would normally allow ASLR bypass, in this context is just a normal bug.

va_list resource leak

• apps/lib/chalk/cif.c:1016

"ArgumentList" was opened line 995 but not closed by va_end

File not closed on exit

• apps/swiss/ssdaemon.c:935
• apps/swiss/ssdaemon.c:939

Leak of "File" opened line 924, never closed.

• uefi/plat/veyron/fwbuild/fwbuild.c:481
• uefi/plat/veyron/fwbuild/fwbuild.c:484

Leak of "KeyBlockFile" opened line 263, never closed.

Memory leak

• apps/setup/win32/io.c:247

"IoHandle" isn't freed on error.

Uninitialized variable

• drivers/dma/bcm2709/dmab2709.c:1511

"Size" is never initialized nor used.

• kernel/armv7/prochw.c:167

If PhysicalMode == TRUE line 131 then InterrupTable is never initialized but
used nonetheless line 167.

Shifting 32-bit value by 32 bits is undefined behaviour

• uefi/plat/panda/init/clock.c:480
• uefi/plat/panda/init/clock.c:908
• uefi/plat/panda/init/clock.c:934
• uefi/plat/panda/init/clock.c:937
• uefi/plat/panda/init/clock.c:977
• uefi/plat/panda/init/clock.c:1003
• uefi/plat/panda/init/clock.c:1019
• uefi/plat/panda/init/clock.c:1050
• uefi/plat/panda/init/clock.c:1051
• uefi/plat/panda/init/clock.c:1057
• uefi/plat/panda/init/clock.c:1063
• uefi/plat/panda/init/clock.c:1069
• uefi/plat/panda/init/clock.c:1075
• uefi/plat/panda/init/clock.c:1081
• uefi/plat/panda/init/clock.c:1091
• uefi/plat/panda/init/clock.c:1093
• uefi/plat/panda/init/clock.c:1098
• uefi/plat/panda/init/clock.c:1100
• uefi/plat/panda/init/clock.c:1102
• uefi/plat/panda/init/clock.c:1108
• uefi/plat/panda/init/clock.c:1110
• uefi/plat/panda/init/clock.c:1112
• uefi/plat/panda/init/clock.c:1114
• uefi/plat/panda/init/clock.c:1116
• uefi/plat/panda/init/clock.c:1123
• uefi/plat/panda/init/clock.c:1125
• uefi/plat/panda/init/clock.c:1127
• uefi/plat/panda/init/clock.c:1129
• uefi/plat/panda/init/clock.c:1140
• uefi/plat/panda/init/clock.c:1146
• uefi/plat/panda/init/clock.c:1152
• uefi/plat/panda/init/clock.c:1152
• uefi/plat/panda/init/clock.c:1162
• uefi/plat/panda/init/clock.c:1164
• uefi/plat/panda/init/clock.c:1166
• uefi/plat/panda/init/clock.c:1168
• uefi/plat/panda/init/clock.c:1175
• uefi/plat/panda/init/clock.c:1177
• uefi/plat/panda/init/clock.c:1179
• uefi/plat/panda/init/clock.c:1181
• uefi/plat/panda/init/clock.c:1182
• uefi/plat/panda/init/clock.c:1183
• uefi/plat/panda/init/clock.c:1185
• uefi/plat/panda/init/clock.c:1187
• uefi/plat/panda/init/clock.c:1188
• uefi/plat/panda/init/clock.c:1190
• uefi/plat/panda/init/clock.c:1192
• uefi/plat/panda/init/clock.c:1198
• uefi/plat/panda/init/clock.c:1208
• uefi/plat/panda/init/clock.c:1221
• uefi/plat/panda/init/clock.c:1222

Dangerous style

SwGetUserNameFromId

This function does not present any bug. However it is dangerous in its use.
In apps/swiss/ls/ls.c for example there is no check of the Result of the
function. The code directly checks that UserName is not NULL. This is an
implementation detail as it is not documented anywhere. With a growing
contributor base and an increasing number of line of code it is bound to
become a bug in the future either because someone changes ls.c without
knowing this implementation detail, or because someone changes
SwGetUserNameFromId thinking everybody uses the return value.

Another point is that we still affect Name to UserName when Name is invalid.
Granted it is NULLed beforehand and there is no bug there. However it doesn't
look resilient to change and one could easily forget to change both the
handling of Name and UserName while updating the function, resulting in the
leak of already freed memory and possible memory corruption.

I would recommend keeping a eye on such a function as experience tells me it
is very likely to give bugs in the future. The best would be to be more
explicite : either document the fact that UserName is NULL on error or remove
its direct use completely. And explicitely NULL UserName on failure instead
on relying on the value of Name to avoid future side-effect.

Similar style can be found elsewhere in the code.

Add support for D package

Vegax 87 requested support for the D programming be added to the repositories in third-party. He writes:

Hi, I discovered Minoca today and I wanna ask you: what do you think about adding D language on Minoca? IMHO D language with Gdc or Ldc2 compiler has achieved excellent results and also is one of the most scalable languages out there and it has a very low memory usage which is perfect for Minoca, I think it deserves a chance to be included on Minoca 3rd-party repos, unfortunately I don't have enough knowledge to port it on Minoca...

P.S: You can see some reliable benchmarks here: https://github.com/kostya/benchmarks

PowerPC Port

Minoca OS lacks support for PowerPC host CPUs.

With the following repositories, I am investigating porting:

• https://github.com/mpasteven/minoca-os
• https://github.com/mpasteven/minoca-third-party-patches

Note that I have not signed the contributor agreement.

There is a stray copy of xcopy.exe in the Minoca gitlab tools respository.

This is a direct link: https://gitlab.com/minoca/tools/blob/master/win32/bin/xcopy.exe

For me this causes the Minoca thirdparty build on Windows to fail because it fails to execute with an "entry point not found error".
Removing this file results in a successful build of the third party tools.
I suggest that it is removed from the repository.

sqlite command fails on reshly built and running minoca instance

Probably missed dependency on readline?

More communication and knowledge storage...

What about...

1. ...starting the Minoca wiki here on GitHub side by side to the code repository?
   Collecting hints and tips and cheat sheets probably will pay back soon...
2. ...defining which IRC server to use for realtime communication?
   IRC is well known and settled and clients grow everywhere and it perfectly works in character based environments. GitHub's text mode Gitter (Gitter bridged to IRC) is a pain and without IRC bridge it needs a running GUI. Probably I'm not the only one who does not like that.

Include opkg on the generated OS image

I'm using the tools repo to set up a build environment on Windows. I can easily build the needed third-party tools and the kernel, as well as individual packages by going to the src/third-party/build/package_name dir and issuing make there.

Is there some make target or other obvious way to include the opkg binary on the generated OS image, so that I can easily install other packages when testing the image on Qemu with run dx?

If this makes any sense, would it also make sense to include the ipkg files of the third-party packages on the disk image of the OS as well (a quick way to have a local repo for opkg inside the image itself)?

consider using sparrow as tool for system tests against running Minoca OS instance

Hi! This is based on https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/minoca-dev/vNyrQ3q0F7w

I have create a super simple but illustrative test suite using sparrow framework, I just looked at http://www.minocacorp.com/documentation/getting-started/tour/ and tried express some points from here as tests.

A test suite page - https://sparrowhub.org/info/minoca-os-test
A test suite source code - https://github.com/melezhik/minoca-os-test
Sparrow framework docs - https://github.com/melezhik/sparrow

I have run this on QEMU instance and this looks good for me.

statvfs issues, Raspberry Pi platform (rpi.img)

No df command. OK, install python and use its os.statvfs facility;

~$ python
python
Python 2.7.5 (default, Apr 30 2016, 22:45:47)
[GCC 4.9.2] on minoca0
Type "help", "copyright", "credits" or "license" for more information.

import os
os.statvfs('/')
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 38] Function not implemented: '/'

~$

Maybe go back to basics and use this program in statvfs.c:

#include <stdio.h>
#include <sys/statvfs.h>

int statvfs(const char *path, struct statvfs *s);

int main()
{
struct statvfs s;
int rc;
rc = statvfs("/", &s);
printf("sizeof f_blocks = %d, f_avail = %d\n", sizeof(s.f_blocks), sizeof(s.f_bavail));
printf("sizeof f_files = %d, f_avail = %d\n", sizeof(s.f_files), sizeof(s.f_favail));
printf("sizeof f_namemax = %d\n", sizeof(s.f_namemax));
printf("blocks=%llu, avail=%llu (%.2f%%), files=%llu, avail=%llu, maxname=%lu\n", s.f_blocks, s.f_bavail, (float) s.f_bavail / s.f_blocks, s.f_files, s.f_favail, s.f_namemax);
return rc;
}

Compiles fine...

~$ gcc -o statvfs statvfs.c
gcc -o statvfs statvfs.c
~$

but the compiled program is not executable:

~$ ls -l
ls -l
total 40
-rw-r--r-- 1 ryniker ryniker 13132 Jan 01 10:15 statvfs
-rw-r--r-- 1 ryniker ryniker 609 Jan 01 09:54 statvfs.c
~$ pwd
pwd
/home/ryniker
~$ id
id
uid=501(ryniker) gid=501(ryniker) groups=501(ryniker)
~$ chmod a+x statvfs
chmod a+x statvfs
chmod: Could not change mode of 'statvfs': Operation not permitted.
~$

Root can change permissions to make the compiled file executable.
Now:

~$ ./statvfs
./statvfs
sizeof f_blocks = 8, f_avail = 8
sizeof f_files = 8, f_avail = 8
sizeof f_namemax = 4
blocks=268596740, avail=17594333523788 (65504.64%), files=1153688929363336160, avail=695529151393660, maxname=39684
~$

NVIDIA Optimus

Hi

Any plans to support NVIDIA Optimus + wine?

Thank you

Headless Operation (ie: On BBB)

I would love to be able to use a serial cable to access the BBB.

Since I'm an embedded developer, most of my "administrative" work is done over SSH and serial cables. It would be nice to be able to edit a text file somewhere, and assign a hardware serial port to the console!

Add asynchronous IO to wishlist

I don't know if any thought has been given to any unique-to-minoca user mode api's, but a proper asynchronous IO mechanism would be nice (preferably using a proactor pattern rather than a polling pattern) .

/etc/issue isn't filled during build

$ cat /etc/issue
Minoca OS %r %m on %l

Adding Golang to third-party repos

Hello, It would be nice to add support golang in minoca, it even possible?

nitpicks

1. is there a reason for INT/LONG proliferation?
2. MIN_CHAR and MIN_WCHAR are signed?
3. mutable strings everywhere, is it a good practice or should one assume that PSTR is always const?
4. what's the reason to use both null terminator and string length including null terminator, can't the terminator be left for posix compatibility layer?
5. is fork,exec combo more efficient than spawning a new process from scratch?
6. headers are licensed under GPL3, this means any software that includes them becomes a derived work and has to comply with GPL?

Please please please consider GPL-3+

If GNU release a later version, then GPL-3 code will probably be incompatible with GPL-4.

Rationale from http://opensource.stackexchange.com/questions/1777/why-is-gplv2-incompatible-with-gplv3:

Both the GPLv2 and the GPLv3 have clauses that

Require the combined product to adhere to the license terms of the license of the GPL licensed component.

Require that no additional restrictions may be placed on the combined work:

from clause 6 of the GPLv2:

Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. (Part 1) You may not impose any further restrictions on the recipients' exercise of the rights granted herein. (Part 2)

The GPLv3 has additional restrictions over the GPLv2, specifically, a patent grant and anti-tivoisation provisions, so 1 and 2 can't hold simultaneously.

To prevent this issue, the Free Software Foundation advises people who want to license their work under the GPL to use the following phrasing:

You can redistribute it and/or modify [the work] under the terms of the GNU General Public License as published by the Free Software Foundation, either version [x] of the License, or (at your option) any later version.

That way, you release your work under multiple licenses; the one you name explicitly, and any possible future version of the GPL. This makes the resuser free to use the software under any future version of the GPL, and this license incompatibility becomes a non-issue.

Running in VirtualBox with vmdk

Hi, want to share my finding with the VirtualBox here

I have tried Evan's method of manually creating the vmdk file to wrap the pc.img, however I get a miss matched uuid stored in the media registry. To fix this I had to copy out the UUID of the ones in the media registry and replace it
ddb.uuid.image="69a7ab8a-ac25-42c6-b673-6c6ca1a36594"

but an easier approach is to have the pc.img and run
VBoxManage internalcommands createrawvmdk -filename pc.vmdk -rawdisk pc.img
which will generate the pc.vmdk for you, now you can just mount the vmdk as is.

hope this helps anyone who may have issues.

Can one build Minoca from Minoca itself?

Screenshots shows running Git, so maybe one can also run the compiler and tools?

There should be FAQ with such question and answer.

macos 10.12.1 build, .incbin macro fails to find ckcore.ck

As reported in #7, macos builds with latest (10.12.1) toolchain (as of nov. 2) fail to find ckcore.ck when expanding the .incbin macro, thus:

Compiling - cdump.c
Assembling - ckcore.S
/Users/seclorum/Documents/minocaOS/src/os/apps/ck/lib/build/../ckcore.S:55:70: error: Could not find incbin file 'ckcore.ck'
.global __binary_ckcore_ck_start; __binary_ckcore_ck_start:; .incbin "ckcore.ck"; .global __binary_ckcore_ck_end; __binary_ckcore_ck_end:
                                                                     ^
make[5]: *** [ckcore.o] Error 1
make[4]: *** [build] Error 2
make[3]: *** [lib] Error 2
make[2]: *** [ck] Error 2
make[1]: *** [apps] Error 2
make: *** [/Users/seclorum/Documents/minocaOS/src/x86dbg/obj/os] Error 2

git clone minoca/third-party over ssh fails

root@Debian-jessie-amd64-netboot:~/minoca# git clone [email protected]:minoca/third-party.git
Cloning into 'third-party'...
The authenticity of host 'gitlab.com (104.210.2.228)' can't be established.
ECDSA key fingerprint is f1:d0:fb:46:73:7a:70:92:5a:ab:5d:ef:43:e2:1c:35.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'gitlab.com,104.210.2.228' (ECDSA) to the list of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

chipPC board support

Could you add image for chipPC board ?
https://getchip.com/pages/chip

Please consider using GMT or UTC for "tzdflt"

(root@minoca:pty2)~# strings /dev/Volume/Volume1/minoca/config/tzdflt 
TmZn,
America/Los_Angeles
P%sT

does it support Displaylink for PI?

it seems that i didnt see the displaylink monitor driver.

x86 Release Build never reaches prompt on qemu-system-i386 or qemu-system-x86_64

It's stuck in this state, with or without KVM:

RSA implementation vulnerable to timing attack+incorrect

The RSA implementation in os/rsa.c uses the Chinese Remainder Theorem without blinding to efficiently decrypt. This introduces a timing attack, slightly different from the published one, where the variance of the runtime as a function of the argument to the reduction leaks the private components of the key. The standard countermeasure is blinding.

Handbook of Applied Cryptography states Barrett reduction potentially requires two subtractions at the end, not just the one performed in the code.

third packages smoke tests on running minoca instance

Hi guys! This is in "a spirit of" - discussion started at https://groups.google.com/forum/#!topic/minoca-dev/vNyrQ3q0F7w

https://github.com/melezhik/minoca-pkg-test

Let me know if sound interesting, so I can go further with other packages.

Deprecated function:

Just cloned, configured env and started build.

Compiling - io.c
/home/ancient/load/os/apps/setup/uos/io.c: In function ‘SetupOsEnumerateDirectory’:
/home/ancient/load/os/apps/setup/uos/io.c:537:9: error: ‘readdir_r’ is deprecated [-Werror=deprecated-declarations]
         Result = readdir_r(Directory, DirectoryEntry, &ResultPointer);
         ^~~~~~
In file included from /home/ancient/load/os/apps/setup/uos/io.c:36:0:
/usr/include/dirent.h:189:12: note: declared here
 extern int __REDIRECT (readdir_r,
            ^~~~~~~~~
cc1: all warnings being treated as errors
make[4]: *** [/home/ancient/load/os/minoca.mk:509: io.o] Error 1
make[3]: *** [/home/ancient/load/os/minoca.mk:383: uos] Error 2
make[2]: *** [/home/ancient/load/os/minoca.mk:383: setup] Error 2
make[1]: *** [/home/ancient/load/os/minoca.mk:383: apps] Error 2
make: *** [/home/ancient/load/os/minoca.mk:93: /home/ancient/load/i6860/obj/os] Error 2
make  35.87s user 2.33s system 87% cpu 43.552 total

hp pro 640 2g green screen...

(dd-ing to usb-stick)

Build GUI

How would I build a GUI ?

IPv6 support?

Embedded ARM Solution

How do you prepare an image to be written to NAND? Is there JFFS2 filesystem option? or something else that may be better for embedded flash?

`opkg` does not use it's config file.

(root@minoca:pty8)~# opkg list-installed

...no output.

(root@minoca:pty8)~# opkg -f /etc/opkg/opkg.conf list-installed | wc -l
     77

Without telling opkg which config file to use, it seems to fail.
(The wc part just keeps the output of the example short.)

(root@minoca:pty8)~# opkg install /src/x86rel/bin/packages/vim_7.4_minoca-i686.ipk 
Not selecting vim 7.4 due to incompatible architecture.
Unknown package 'vim'.
Collected errors:
 * opkg_install_cmd: Cannot install package vim.
(root@minoca:pty8)~# opkg -f /etc/opkg/opkg.conf install /src/x86rel/bin/packages/vim_7.4_minoca-i686.ipk
Installing vim (7.4) on root.
Configuring vim.

...so without config file it does not even know the architecture and won't accept packages for minoca-i686. opkg defaults to only acceppt architecture all by default. Again, it works as expected when adding -f /etc/opkg/opkg.conf.

Can someone confirm this behaviour or do I have a local problem here?

Wishlist link broken on community page

On the community page at the bottom, the link to the wishlist is given as:
https://github.com/minoca/os/WISHLIST.md
but should instead be:
https://github.com/minoca/os/blob/master/WISHLIST.md

This was the first link I found looking for where to find the source. (I missed the fork-me banner somehow.) Would be nice if it were more prominent.

Building for Transmeta Crusoe (or simply i586 in general)?

What is neccessary to build Minoca for a Transmeta Crusoe based system?

Can I just try the x86q port?

I've got some Fujitsu Siemens Futro S220 thin clients idling and collecting dust which previously were used as x86-OpenWrt guinea pigs. Typically they have 128M RAM and a filesystem on a 128M CF but I can upgrade some of them to 512M RAM (their maximum), 512M CF card (or more but not at hand) and if that's not enough they can boot or run from USB (tested with i586ish Linux) or I can add a harddisk.

Compiling on OSX

After pulling in the fix for ckcore I run into a new issue when compiling under OSX. I'm using the Howebrew GCC, but I have also experienced issues with Xcode 8 and Xcode CLI tools. Could you maybe document the recommended compiler/environment for building?

Compiling - uos.c
/Users/johan/Projecten/raspberrypi/os/apps/swiss/uos/../swlib/uos.c: In function 'SwGetMonotonicClock':
/Users/johan/Projecten/raspberrypi/os/apps/swiss/uos/../swlib/uos.c:3158:12: error: implicit declaration of function 'clock_gettime' [-Werror=implicit-function-declaration]
     return clock_gettime(CLOCK_MONOTONIC, Time);
            ^~~~~~~~~~~~~
/Users/johan/Projecten/raspberrypi/os/apps/swiss/uos/../swlib/uos.c:3158:26: error: 'CLOCK_MONOTONIC' undeclared (first use in this function)
     return clock_gettime(CLOCK_MONOTONIC, Time);
                          ^~~~~~~~~~~~~~~
/Users/johan/Projecten/raspberrypi/os/apps/swiss/uos/../swlib/uos.c:3158:26: note: each undeclared identifier is reported only once for each function it appears in
/Users/johan/Projecten/raspberrypi/os/apps/swiss/uos/../swlib/uos.c:3159:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
/Users/johan/Projecten/raspberrypi/os/apps/swiss/uos/../swlib/uos.c: At top level:
cc1: error: unrecognized command line option '-Wno-parentheses-equality' [-Werror]
cc1: all warnings being treated as errors
make[5]: *** [swlib/uos.o] Error 1
make[4]: *** [uos] Error 2
make[3]: *** [swiss] Error 2
make[2]: *** [apps] Error 2
make[1]: *** [/Users/johan/Projecten/raspberrypi/armv6dbg/obj/os] Error 2
make: *** [img] Error 2

~/P/raspberrypi (master|✚5…2) $ ls -l (which gcc); armv6dbg/tools/bin/arm-none-minoca-gcc --version; gcc --version; sw_vers
lrwxr-xr-x  1 johan  staff  28 Nov  2 22:49 /Users/johan/Projecten/raspberrypi/.bin/gcc -> /Users/johan/.brew/bin/gcc-6
arm-none-minoca-gcc (GCC) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

gcc (Homebrew gcc 6.2.0) 6.2.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ProductName:	Mac OS X
ProductVersion:	10.11.6
BuildVersion:	15G1108

Include win32 binary of pkg-config on the tools repo

I've been trying to port new packages to Minoca OS using the Windows cross-compiling environment and some of those packages require pkg-config.

I simply grabbed a binary here: http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/pkg-config_0.26-1_win32.zip and moved on with configuration/compilation.

Since this is so ubiquitous, would it be possible to include it on the tools repo for Windows?

MinocaOS startrer - can't set memory size more than 1024 MB

start .\Qemu\qemu.exe -L .\Qemu -m 1024-hda .\Minoca\Image\pc.img -serial pipe:minocapipe -net nic,model=i82559er -net user

When I set -m to a number more than 1924 and then launch run.bat , starter does not up ( see no green terminal screen ). My Host OS has about 10 GB available memory though ...

HP ProBook6470b

HP ProBook6470b is not booting

Chalk

Hi,
it seems you are using some language called "Chalk" throughout the project.

Is it something that existed before Minoca or it was developed for this project only?

Hyper-V VM doesn't work

Hello, I want to test Minoca OS using Hyper-V 2016 server. But unfortunately, OS can't initialize properly, it can't finish boot sequence. All I can see is initial information. Any ideas, how can I force it to start?

Crossbuilt cmake probably is a linux executable

(root@minoca:pty14)~# cmake
-bash: /usr/bin/cmake: cannot execute binary file: Exec format error
(root@minoca:pty14)~# strings /usr/bin/cmake | head -1
/lib64/ld-linux-x86-64.so.2

Keyboard not working on lenovo s10-3c

=(

x86dbg build on macos/linux 10.12.1 fails stdio.h inclusion ..

Hiya minoca OS folks,

Quite interested in minocaOS, I immediately cloned the repo, downloaded the toolchain for my dev system (macOS 10.12.1), set up the paths, .'ed my setenv.sh, and attempted a fresh, clean build as an interested OS developer is wont to do..

Out of the box tho', seems that something is borked:

$ cat ../../setenv.sh
export SRCROOT=~/Documents/minocaOS/src
export ARCH=x86
export VARIANT=
export DEBUG=dbg
export PATH=$PATH:$SRCROOT/$ARCH$VARIANT$DEBUG/tools/bin
 seclorum@github:~/Documents/minocaOS/src/os {(master)}
$ gb -av
* master                0cb08c9 Makefile build fix.
  remotes/origin/HEAD   -> origin/master
  remotes/origin/master 0cb08c9 Makefile build fix.
 seclorum@github:~/Documents/minocaOS/src/os {(master)}
$ ls
CONTRIBUTING.md WISHLIST.md     docs            include         new.c
LICENSE         apps            drivers         kernel          new.h
Makefile        boot            env.ck          lib             tasks
README.md       build.ck        images          minoca.mk       uefi
 seclorum@github:~/Documents/minocaOS/src/os {(master)}
$ make
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/basevid
make[3]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/basevid
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/bconflib
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/bconflib/build
make[4]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/bconflib/build
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/bconflib
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base/boot
make[5]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base/boot
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base/build
make[5]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base/build
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base/intrins
make[5]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base/intrins
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base/wide
make[5]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base/wide
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/base
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/kmode
make[4]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/kmode
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/rtlc
Entering Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/rtlc/build
make[5]: Nothing to be done for `all'.
Leaving Directory: /Users/seclorum/Documents/minocaOS/src/os/lib/rtl/rtlc/build
Compiling - stubs.c
/Users/seclorum/Documents/minocaOS/src/os/lib/rtl/rtlc/stubs.c:35:19: fatal error: stdio.h: No such file or directory
 #include <stdio.h>
                   ^
compilation terminated.
make[4]: *** [stubs.o] Error 1
make[3]: *** [rtlc] Error 2
make[2]: *** [rtl] Error 2
make[1]: *** [lib] Error 2
make: *** [/Users/seclorum/Documents/minocaOS/src/x86dbg/obj/os] Error 2
 seclorum@github:~/Documents/minocaOS/src/os {(master)}
$ find .. -name "stdio.h" -print
../armv7dbg/tools/lib/gcc/arm-none-minoca/4.9.2/include/c++/tr1/stdio.h
../armv7dbg/tools/lib/gcc/arm-none-minoca/4.9.2/include/ssp/stdio.h
../armv7dbg/tools/usr/include/stdio.h
../os/apps/libc/include/stdio.h
../x86dbg/tools/lib/gcc/i686-pc-minoca/4.9.2/include/c++/tr1/stdio.h
../x86dbg/tools/lib/gcc/i686-pc-minoca/4.9.2/include/ssp/stdio.h
../x86dbg/tools/usr/include/stdio.h
 seclorum@github:~/Documents/minocaOS/src/os {(master)}

Any clues what I may have exposed here? Perhaps the rtl build is looking for stdio.h in strange places, and not finding it .. anyway, thought I'd report this issue before I come back in a few hours and have another round (next time on a Linux-x64 system..)

Software package request

a software request:
gluster
mono
openzfs

Minoca OS fails to boot in VMWare

hi @Tester768 . Let's move our VMWare thread over here.

Thanks for getting a kernel debugger connected, that helps a lot. The 0.2.0.1375 failure is now understood. From the diff of the two we can see that in 0.2.0.1375 all devices underneath the ISA bus fail, which explains why the keyboard never comes up. In the newer build we see many more devices being enumerated, so we're making progress :)

It seems like some part of the build process isn't getting sh into the right place. Do you have sh, mount, and a few other apps in x86dbg/bin/skel/bin? If not, I wonder if the -nt (newer than) test is not passing for non-existent files during the build process.

Can you try replacing lines 66-68 of apps/swiss/Makefile with just
$(STRIP) -o $(BINROOT)/skel/bin/sh $(BINROOT)/$(BINARY)

and do a make clean + rebuild (essentially just removing the if). If removing the conditional causes sh to show up in x86dbg/bin/skel/bin, then we'll know that's the issue. To fully boot we'll also need to do that fix for mount's postbuild.

No x64 support?

Is there any plans to x64 support?

Consider adding GPLv3 licensing to Makefiles

While browsing through the code, I noticed that the change in licensing was only for the source files and not the Makefiles. It would be nicer if they were included, if possible.

NVidia GPU drivers support?

NVidia GPU drivers support?