Giter Club home page Giter Club logo

microkernel's Introduction

Nanvix

Join us on Slack!

What Is Nanvix?

This repository hosts the educational version of Nanvix.

Nanvix is a Unix-like operating system written by Pedro Henrique Penna for educational purposes. It is designed to be simple and small, but also modern and fully featured.

What Hardware Is Required?

Nanvix targets 32-bit x86-based PCs and only requires a floppy or CD-ROM drive and 16 MB of RAM. You can run it either in a real PC or in a virtual machine, using a system image.

License and Maintainers

Nanvix is a free software that is under the GPL V3 license and is maintained by Pedro Henrique Penna. Any questions or suggestions send him an email: [email protected]

microkernel's People

Contributors

antoinesaget avatar hansb21 avatar joaofel-u avatar joaovicentesouto avatar jordanjean avatar joseguilhermecr avatar lucasandradecb avatar nicolasvanz avatar ppenna avatar rafael0121 avatar ravixr avatar samuelvlc avatar theldus avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

microkernel's Issues

[ikc] Virtual Mailboxes

Description

We should provide a Virtual Mailbox abstraction on top LwIP, for targets that feature an Ethernet interface but not a NoC.

Related Issues

[dev] Device System Kernel Interface

Description

  • intcl(): controls the behavior of an interrupt

  • intwait(): waits for the delivery of an interrupt

  • intreturn(): returns from an interrupt handler

  • iograb(): allocates an I/O port

  • iorelease(): releases an I/O port

  • ioread(): reads from an I/O port

  • iowrite() writes to an I/O port

  • mmiograb(): allocates a memory mapped I/O region

  • mmiorelease(): releases a memory mapped I/O region

  • mmioread(): reads from an memory mapped I/O region

  • mmiowrite(): writes to a memory mapped I/O region`

[kcall] Automatically Update Number of Kernel Calls

Description

Currently, whenever we add a new kernel call, we should update NR_SYSCALLS. If we are not cautious, this may introduce a bug in the kernel.

Instead, we should create a constant NR_last_kcall with the last kernel call number and make NR_SYSCALLS expand to it.

[ikc] Portals

Description

In targets that feature a NoC, we should provide a portal abstraction.

A portal enables processes running on different clusters to exchange airbtraty amounts of data with one another.

[thread] Unit Tests for Thread Management Kernel Calls

Description

The following testing units for the thread management kernel calls should be designed and implemented:

  • API: thread identification (8a257e5)
  • API: thread creation/termination (8a257e5)
  • Fault Injection: thread creation with invalid starting routine (8a257e5)
  • Fault Injection: thread creation with bad starting routine (f0b3d20)
  • Fault Injection: thread creation with bad argument (24a05a2)
  • Fault Injection: terminate a thread with bad return value (b7acd36)
  • Fault Injection: spawn too many threads (8a257e5)
  • Fault Injection: join an invalid thread (8a257e5)
  • Fault Injection: join a bad thread (8a257e5)
  • Fault Injection: join a thread with bad return value (dce8cd5)
  • Stress: spawn and join many threads (8a257e5)

[mm] Unit Tests for the Page Frame Allocator Subsystem

Description

The following unit tests for the Page Frame Allocator subsystem should be designed and implemented:

  • API Test: Page Frame Address Translation (7392b2b)
  • API Test: Page Frame Allocation (7392b2b)
  • Fault Injection Test: Invalid* Page Frame Address Translation (7392b2b)
  • Fault Injection Test: Invalid* Page Frame Release (7392b2b)
  • Fault Injection Test: Bad* Page Frame Release (7392b2b)
  • Fault Injection Test: Double Page Frame Release (7392b2b)
  • Fault Injection Test: Page Frame Allocation Overflow (7392b2b)
  • Stress Test: Page Frame Allocation (7392b2b)

* In Fault Injection Tests, "invalid" means logically not possible and a "bad" semantically not possible.

[ikc] Virtual Portals

Description

We should provide a Virtual Portal abstraction on top LwIP, for targets that feature an Ethernet interface but not a NoC.

Related Issues

[tests] Re-Enable TravisCI Run for Unix 64-bit

Description

In commit 07086f9 we have disabled TravisCI runs for the Unix 64-bit target. We did so because the following functionalities are somewhat unstable in this target, which in turn cause regression tests to fail too often:

  • Overall functioning of mutexes/semaphores
  • Spawn and join kernel threads in a tight loop

[thread] Rely on Nulll Thread ID

Description

In commit 0b9778f we have introduced an kernel thread identifier for meaning no thread at all.

We should change the thread system accordingly to make use of this enhancement.

Updates

Enhancement introduced in commit 503956f.

[ikc] Missing LwIP Install

Description

In the contrib/makefile.install we are missing the installation of the LwIP static library.

[thread] Retry Thread Create for a Finite Number of Times

Description

Currently, we retry thread creation (thread_create()) for an infinite number of times, if the target core is not yet in idle state (core_start() fails with EBUSY).

We should do that only for some time instead, to avoid a kernel lock up.

[mm] Memory System Kernel Calls

Description

The following interface should be exported by the kernel so as to enable user-level programs to manipulate the memory.

Functions

  • err = pgmap(vaddr, mode): maps a page into memory
  • err = pgunmap(vaddr): unmaps a page from memory
  • err = pgctl(vaddr, mode): changes features of a page

[test] Unit Tests for Kernel Calls

Description

The following unit tests for assessing the Kernel Calls should be introduced.

API Tests

  • Sanity Check Execution Context After a Kernel Call

Fault Injection Tests

  • Issue an Invalid Kernel Call
  • Issue a Bad Kernel Call
  • Issue a Kernel Call from a Bad Execution Context
  • Issue a Kernel Call from an Invalid Execution Context

[hal] Standard Logging Format

Description

We are currently messing the kernel logs, by using different string formats to log the output. We should stick to a standard formatting for kernel logs, so it becomes easier to debug with automated tools.

[ikc] Mailboxes

Description

In targets that feature a NoC, we should provide a mailbox abstraction.

A mailbox enables processes running on different clusters to exchange fixed-size messages with one another.

[test] Unit Tests for Signals

Description

We should introduce the following unit tests to assess the Signal Kernel Calls.

API Tests

  • Register and Unregister a Signal Halder (a9e9f2a)
  • Trigger a Signal and Handle It

Fault Injection Tests

  • Register an Invalid Signal Handler (a9e9f2a)
  • Register a Bad Signal Handler

[ikc] Syncs

Description

In targets that feature a NoC, we should provide a synchronization point (sync) abstraction.

A sync enables processes running on different clusters to synchronize their work with one another.

[mm] User Page Pool

Description

The Kernel Page Pool is a subsystem of the Memory System that maintains a pool of pages for user use. Overall, this subsystem exposes an interface for allocating, releasing mapping and unmapping user pages.

Interface Overview

  • upage_alloc(): allocates a user page

  • upage_free(): releases a user page

  • upage_map(): maps a user page

  • upage_unmap(): unmaps a user page

  • Feature: User Page Pool

[ikc] Virtual Syncs

Description

We should provide a Virtual Sync abstraction on top LwIP, for targets that feature an Ethernet interface but not a NoC.

Related Issues

[tests] Re-Enable Unit Tests

Description

The following unit tests were intentionally disabled, due to unknown issues.

We should track and fix related bugs and then re-enable these tests.

All Targets

  • Thread Sleep/Wakeup Stress
  • Thread Bad Start
  • Thread Bad Argument
  • Thread Bad Join
  • Thread Stress

Unix 64-bit

  • Performance Interface
  • Signal Interface

[mm] Page Frame Allocator

Description

The Page Frame Allocator is a subsystem of the Memory System that provides a facility for allocating and releasing page frames.

Interface Overview

  • frame_alloc(): allocates a page frame
  • frame_free(): releases a page frame

Related Commits

[thread] Signals Kernel Calls

Description

The following interface should be supported, in order to enable threads to catch, send and manage signals.

Structures

  • struct sigaction: describes actions on the receipt of a signal

Functions

  • err = alarm(sec): schedules an alarm signal
  • err = sigsend(signum, tid): sends a signal
  • err = sigwait(signum): waits for the receipt of a signal
  • err = sigctl(signum, &sigact): controls the behavior of a signal
  • sigreturn(): returns from a signal handler

Roadmap

  • sigctl() introduced in commit a9e9f2a.

[mm] Unit Tests for the User Page Pool Subsystem

Description

The following unit tests for the User Page Pool subsystem should be designed and implemented:

  • API Test: User Page Translation (7392b2b)
  • API Test: User Page Allocation (7392b2b)
  • API Test: User Page Write (7392b2b)
  • Fault Injection Test: Invalid* Kernel Page Allocation (7392b2b)
  • Fault Injection Test: Double User Page Allocation (7392b2b)
  • Fault Injection Test: Invalid* Kernel Page Release (7392b2b)
  • Fault Injection Test: Bad* User Page Release (7392b2b)
  • Fault Injection Test: Double User Page Release (7392b2b)
  • Fault Injection Test: User Page Allocation Overflow (7392b2b)
  • Stress Test: User Page Allocation (7392b2b)
  • Stress Test: User Page Write (7392b2b)

* In Fault Injection Tests, "invalid" means logically not possible and a "bad" semantically not possible.

[mm] Unit Tests for the Kernel Page Pool Subsystem

Description

The following unit tests for the Kernel Page Pool subsystem should be designed and implemented:

  • API Test: Kernel Page Translation (7392b2b)
  • API Test: Kernel Page Allocation (7392b2b)
  • API Test: Kernel Page Write (7392b2b)
  • API Test: Kernel Page Clean Allocation (7392b2b)
  • Fault Injection Test: Invalid* Kernel Page Release (7392b2b)
  • Fault Injection Test: Bad* Kernel Page Release (7392b2b)
  • Fault Injection Test: Double Kernel Page Release (7392b2b)
  • Fault Injection Test: Kernel Page Allocation Overflow (7392b2b)
  • Stress Test: Kernel Page Allocation (7392b2b)
  • Stress Test: Kernel Page Write (7392b2b)

* In Fault Injection Tests, "invalid" means logically not possible and a "bad" semantically not possible.

[thread] Thread Management Kernel Calls

Description

The following interface should be exported by the kernel so as to enable user-level programs to spawn, synchronize and terminate kernel threads.

Types

  • kthread_t: used for uniquely identify a kernel thread

Functions

  • tid = kthread_self(): returns the identifier of the calling kernel thread
  • err = kthread_create(&tid, &start, &args): creates a new kernel thread
  • err = kthread_exit(status): terminates the calling kernel thread
  • err = kthread_join(tid, &status): waits for a kernel thread to terminate

Related Commits

[thread] Kernel Thread Number

Description

Currently kernel threads can be uniquely identified by IDs, but somewhats it is useful to have a logic numbering from 0 to THREAD_MAX to address them.

Indeed, we have been so far using the ID of the core in which the thread is attached to (ie. coreid), but that is ugly.

[mm] Kernel Page Pool

Description

The Kernel Page Pool is a subsystem of the Memory System that maintains a pool of pages for kernel use. Overall, this subsystem exposes an interface for allocating and releasing kernel pages, thereby providing the bare-bones for dynamic memory allocation in kernel land.

Interface Overview

  • kpage_get(): allocates a kernel page
  • kpage_put(): releases a kernel page

Related Commits

[thread] Thread Join Unblocks and Exiting Threads

Description

Currently, whenever a thread exits it waits on a conditional variable for another thread to join it. The problem however, comes from the fact that there is a single conditional variable for the whole thread system, thus causing all threads that are exiting to be unblocked.

We should fix this problem by introducing a conditional variable for kthread_exit(), for each kernel thread.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.