Ghost Kernel

Threaded system calls & kernel-privilege thread support added 2019/03/04, 22:38:10

The redux branch has now support for kernel-level threads and threaded system calls. The previous implementation only supported userspace-threads which had some advantages but also made specific call implementations more complicated. This approach will improve efficiency and allows a better scheduling implementation in the long run.

There were some interesting problems to solve; due to the fact that a kernel thread might get interrupt while holding a kernel lock, the gmutex implementation must now keep track of the number of locks held per processor. As long as a task holds kernel locks, no other task will be scheduled until the task is finished with its work.

System calls can now be registered as threaded or direct calls. When a threaded call is executed, the respective handler is called within a kernel-level thread. These processing tasks are reused for successive system calls by the same task. This allows preemption during call processing and avoids blocking the scheduler for long-running requests.

Comments

Write a comment...
  • Hamidreza 2019/05/30, 23:55:09

    hello friend!

    I'm happy to your coming back.

    Please continue to developing.

    Thanks

  • Martin Vahi 2019/03/08, 02:33:18

    You may want to study the ideas behind the ParaSail programming language, when developing some threading model. One of the peculiarity of the ParaSail programming language is that it is a systems programming language that is meant to be used with safety critical systems, has formal verification tools designed right into the language from the very start and is designed to work with 1000+ core CPUs by using a new threading model that minimizes the threading related burden of software developers. As of the writing of this comment, the newest version is the ParaSail_8.0

    https://groups.google.com/forum/#!topic/parasail-programming-language/tt8MMqtV8k8

    but repackaged older versions can be found from my home page at

    https://technology.softf1.com/softwarebythird_parties/ParaSail/

    The older versions might be easier to build, specially the version 6.5, which does not have a fast implementation, but is good enough for studying the ideas behind the ParaSail.

    I am NOT a ParaSail author. The ParaSail is created/invented by the Ada language designer, the Tucker Taft, who designed it as a summary of all of his life long language design knowledge. The purpose was to create a brand new systems programming language that is not just "a better C", but that takes to account the formal verification achievements from the very start, since the design phase of the language and that is designed with perfection in mind, without needing to support any old legacy code. The nice thing about the ParaSail is that it is not yet-another-academic-one-off-project that is dumped the moment grant money runs out or papers get published or thesis gets defended. The ParaSail is actually designed by an industrial developer, the Tucker Taft, and it is meant to be PRACTICAL in industrial scenarios. As of 201903 the downside of the ParaSail is the legal uncertainty: it's GPLv3 and the Tucker Taft claims that the stdlib is in public domain and according to his 201903 understanding the development of commercial, closed source, software is not limited by the current ParaSail license, but I believe that as there is no clear statement about that in the ParaSail sources, the situation can be interpreted both ways, so from my point of view the ParaSail stdlib is under GPLv3. But it is still a remarkable project for learning, self education.

    Thank You for reading my comment.

  • Guillaume 2019/03/06, 08:57:37

    Hi !

    I have a question about the kernel-level thread created for syscalls : do you mean that this thread, once created, will live until user thread (or user process ?) die ?

    I always thought that having kernel-level threads was necessary to create a kernel, I can see that it's not an obligation but it seems necessary in your case ?

    • Max 2019/03/06, 09:32:09

      Hi Guillaume!

      The kernel-level thread that is created is only scheduled until the syscall is finished; it then gets the state "unused" but the allocated structures (stack etc.) stay alive. Once the user thread finishes, this processing thread is also deleted. I'm thinking about sharing those unused threads between multiple user threads though to improve this more.

      Well, in the existing (master branch) implementation of Ghost, there are only Ring 3 threads, no Ring 0 at all. This had the advantage that faulty code would less frequently kill the entire system. But in this first approach I did, there are also many limitations. System calls could not be interrupted. When you needed some thread to do stuff that would normally require kernel-permissions, there had to be a system call for every bit of work. All of that increased latency a lot.

      Greets

    • Guillaume 2019/03/06, 12:46:51

      Yes I think you could use this same kernel-level thread for all threads of the same process ? (all these threads sharing the same virtual memory space...).

      I don't understand why your System calls couldn't be interrupted ? If an interrupt occurred, the kernel just has to switch to a new kernel stack (associated to the user thread) for this interrupt. In this way, the kernel stack used for the syscall is not corrupted by the interrupt. But maybe I didn't understand the problem your are talking about...

      Anyway thank you for your answer !

    • Max 2019/03/06, 12:52:51

      What I mean with that is, it is pretty hard to properly make the interrupt handlers preemptible. During interrupt handling, another interrupt could be fired, which would push again onto the current kernel stack. Using kernel level threads for the syscall handling I can avoid interrupting the system call handler.

    • Guillaume 2019/03/06, 12:59:41

      Ok I understand, I didn't come far enough in my project to have this problem I guess...

      Thank you for your answers and have a nice day ;)

    • Max 2019/03/06, 15:24:10

      Sure! Good luck with your project :-)

Cancel