Go, operating systems, and system programming.

2,252 views
Skip to first unread message

Jonathan Elijah

unread,
Jun 9, 2012, 5:50:55 PM6/9/12
to golang-nuts
I'm new to programming, only started learning it about a month ago,
and have spent most of that time learning Python. I took a while to
think about my overall goals for getting into programming, and have
come to the conclusion that I want to focus on the area of operating
systems and system programming. This is obviously a huge challenge,
and I don't propose anything magnificent from these goals, but is it
possible for Go to be used in the overall development of an operating
system? I am aware that assembly will always be needed for some areas
of this subject matter.

Again, I am new to this realm. I know C is generally the primary
language used in OS design for various reasons, all of which I have no
thorough understanding of, but am aware that the likely number one
reason for C being king in this realm is its access to memory and
closeness to the hardware (being low-level for the most part). I've
read in a source about Go that it is being referred to as a more
modern C (read it in The Way to Go by Ivo Balbaert), and also stated
that Go can be used for system programming. Thus I have to end my
futile attempt at sounding smart and ask: can Go be used in the
overall development of an operating system?

Devon H. O'Dell

unread,
Jun 10, 2012, 1:28:17 AM6/10/12
to Jonathan Elijah, golang-nuts
At one time, there was an example toy kernel in the Go repository. I
don't recall the timeline, but if you look at the mercurial log, I'm
sure you can find it with relative ease. I was able to boot it and
play a bit with it on VirtualBox a year or so back. Hopefully that
gets you at least a bit further in your endeavors! :)

--dho

2012/6/9 Jonathan Elijah <em...@jonathanelijah.com>:

andrey mirtchovski

unread,
Jun 10, 2012, 1:32:12 AM6/10/12
to Devon H. O'Dell, Jonathan Elijah, golang-nuts
/src/pkg/runtime/tiny, removed one year, four months ago by this CL:

http://codereview.appspot.com/3996047/

Toni Cárdenas

unread,
Jun 11, 2012, 12:58:31 AM6/11/12
to golan...@googlegroups.com
There is also this: http://gofy.cat-v.org/

Kyle Lemons

unread,
Jun 11, 2012, 5:22:56 PM6/11/12
to Jonathan Elijah, golang-nuts
It all depends on what you mean by "operating system" and what goals you have.  If you want to blaze a new trail and create a "go os" that is entirely statically linked with its applications which are all goroutines as an experiment in concurrency, that's much different from wanting to write a kernel that provides APIs for userland and system calls that are e.g. compatible with linux.

As was mentioned, there used to be a "tiny" runtime that was able to run Go without help from a kernel.  This turns out to be rather a challenge, as you can't use any syscalls that you don't implement yourself.  I would personally love to see someone take on the project of resurrecting it, since I'd love to run Go on a microcontroller, but the chances of that happening any time soon (if ever) seems remote.  That being said, it would be "reasonable" to create an entire operating system on top of a particular kernel (linux, darwin, bsd, and plan9 are probably the easiest), including the usual shells, utilities, etc (gofy, linked earlier, is one example of such a project).  Depending on how you architected it, you might find that the current lack of a dynamic loader would get in the way, but various IPC and other plugin architectures can mitigate some of that.

Jeff R. Allen

unread,
Jun 12, 2012, 7:13:11 AM6/12/12
to golan...@googlegroups.com
I worked on the Tiny runtime for Go for a while, even after it was removed from the Go tree. It finally died a flaming death when Russ checked in the new memory management system, which uses a huge area of uninitialized memory from mmap as a bitfield to keep track of what pages from the entire address space are used for what. With virtual memory, the OS arranges for this giant range of zeros (as I recall, it's over 700 megs on a 32-bit machine, and much more on 64-bit) to exist with only a few pages of real memory backing it (only pages that have bits set in it need backing). For the tiny runtime, this was a huge problem; the solution would have been to replace a significant part of the memory management machinery inside of the Go runtime, and I didn't care enough to do that, so I packed it in and moved on to other toys.

To the OP, you should have a read here: http://wiki.osdev.org/Introduction

  -jeff

Aram Hăvărneanu

unread,
Jun 12, 2012, 7:42:16 AM6/12/12
to Kyle Lemons, Jonathan Elijah, golang-nuts
> That being said, it would be
> "reasonable" to create an entire operating system on top of a particular
> kernel (linux, darwin, bsd, and plan9 are probably the easiest), including
> the usual shells, utilities, etc (gofy, linked earlier, is one example of
> such a project).

Gofy used a bare metal kernel, it started from the tiny runtime.

--
Aram Hăvărneanu

Jonathan Elijah

unread,
Jun 13, 2012, 10:43:54 AM6/13/12
to golang-nuts
Thanks all for your reply and the discussion about projects past and
current using Go. I'll look into things further since it seems to be
possible with some (read much) work.

unread,
Jun 14, 2012, 10:28:26 AM6/14/12
to golan...@googlegroups.com
On Thursday, June 14, 2012 1:16:31 PM UTC+2, paulo....@gmail.com wrote:
A language like Go is quite capable for OS development.

One of the features of an OS is that it needs to be defined what happens when it exhausts memory. Therefore an OS requires a programming language with explicit memory management. From this also follows the need to stop or kill a process in order to keep the OS running.

Go will allocate memory on various occasions. For example, it may need to allocate memory when converting a value from one interface{...} to another interface{...}.

In the C language, memory gets allocated as a side-effect of language design only when calling a C function (the call will result in the allocation of a new stack frame).

In the Go language, there are more places (in comparison to C) where memory gets allocated as a side-effect of language design.

In an assembly language, there are no such places in the language design. There do exist the CALL and PUSH instructions, but their usage isn't mandatory.

A difference between assembler and C/Go is that it is impossible to estimate the memory requirements of a task prior to starting the task. This is because the C/Go language and compiler are hiding information such as the sizes of stack frames of functions.

Andrew Jackman

unread,
Jun 13, 2014, 10:32:52 AM6/13/14
to golan...@googlegroups.com, em...@jonathanelijah.com
I am excited about the Go OS, also. Please take a look at my comments in another thread:


Please let me know how you've been doing.

Thanks!
Reply all
Reply to author
Forward
0 new messages