Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gopher-OS: A Proof of Concept OS Written in Go

github.com

Post reply on HN
Print view View original

21–30 of 84 posts

Re: Gopher-OS: A Proof of Concept OS Written in Go

#21

Post by weberc2 »

dullgiulio wrote: post #17
weberc2 wrote: post #11

I don't know anything about OS development, but how do you implement an OS in a language whose runtime depends on an OS?

Well, the Go runtime is written in Go itself. And you can write Go without the runtime, the same way the compiler is. The hard part is that the runtime is indeed build on OS primitives (syscall mostly), that you have to implement yourself. You have to forgo all the niceties of having a runtime but you can do it. Definitely not the most productive use of Go, but it's fun and you learn a lot.

> And you can write Go without the runtime, the same way the compiler is.

The compiler does depend on the runtime AFAIK

> The hard part is that the runtime is indeed build on OS primitives (syscall mostly), that you have to implement yourself.

This is what I was referring to. I don't know how you would do this without patching the language.

Re: Gopher-OS: A Proof of Concept OS Written in Go

#22

Post by haberman »

dullgiulio wrote: post #17
weberc2 wrote: post #11

I don't know anything about OS development, but how do you implement an OS in a language whose runtime depends on an OS?

Well, the Go runtime is written in Go itself. And you can write Go without the runtime, the same way the compiler is. The hard part is that the runtime is indeed build on OS primitives (syscall mostly), that you have to implement yourself. You have to forgo all the niceties of having a runtime but you can do it. Definitely not the most productive use of Go, but it's fun and you learn a lot.

> Well, the Go runtime is written in Go itself.

That's a bit of a stretch. The runtime uses special pragmas that are not available to normal programs. I don't think it would be possible to write Go's GC in Go unless these special pragmas existed:

https://github.com/golang/go/blob/57df2f802f0417f08100ff8002...

Also, there are magical variables in the runtime that the compiler knows about and special-cases: https://github.com/golang/go/blob/57df2f802f0417f08100ff8002...

> And you can write Go without the runtime, the same way the compiler is.

How would you write Go without using the GC?

Re: Gopher-OS: A Proof of Concept OS Written in Go

#23

Post by weberc2 »

bpicolo wrote: post #16
weberc2 wrote: post #11

I don't know anything about OS development, but how do you implement an OS in a language whose runtime depends on an OS?

Looks like it's a matter of not importing almost any libraries other than "unsafe".

Not only that, but you'd have to take care not to do anything that would trigger an allocation, since you don't have memory management.

Re: Gopher-OS: A Proof of Concept OS Written in Go

#24

Post by acomjean »

weberc2 wrote: post #11

I don't know anything about OS development, but how do you implement an OS in a language whose runtime depends on an OS?

You generally don't. Thus the "proof of concept".

Though to be fair a lot of the standard C libraries have there own "Linux" version in the Kernel so the OS can do things without using the OS...

http://lxr.linux.no/linux+v4.10.1/include/linux/

Re: Gopher-OS: A Proof of Concept OS Written in Go

#26

Post by achilleasa »

Hi, I am the author of gopher-os. It started as a fun research project to learn more about the Go runtime internals and I didn't really expect it making it to HN.

If you take a look at the Go runtime sources you will notice that all the low-level arch/os-related bits have been split into separate files which usually invoke some syscalls (e.g. the memory allocator eventually calls mmap)

The idea I am currently investigating is to first provide an implementation for things such as physical memory allocation and virtual memory mapping which would ultimately allow me to bootstrap the Go allocator. From that point onwards the plan is to incrementally add more features and gradually initialize the rest of the runtime.

This is much more difficult than it sounds as all code must be written in such a way to prevent the compiler from calling the runtime allocator (no variables allowed to escape to the heap).

Re: Gopher-OS: A Proof of Concept OS Written in Go

#29

Post by driusan »

achilleasa wrote: post #26

Hi, I am the author of gopher-os. It started as a fun research project to learn more about the Go runtime internals and I didn't really expect it making it to HN. If you take a look at the Go runtime sources you will notice that all the low-level arch/os-related bits have been split into separate files which usually invoke some syscalls (e.g. the memory allocator eventually calls mmap) The idea I am currently investi…

I started writing a kernel in Go a while ago (and since abandoned it due to not having time.. I got as far as having a simple built in shell that let you do ls and cat on a FAT filesystem). The part about memory allocation and virtual memory wasn't much more difficult than it would be if you were implementing your kernel in C or some other low level language.

The hard part is once you get memory and paging working, you'll need a syscall interface. If you want to be able to run Go userspace programs, that means you need to implement the syscall interfaces for an OS that's already supported, and can't just go out and design your own, and at that part it starts getting a lot less fun.

Re: Gopher-OS: A Proof of Concept OS Written in Go

#30

Post by barsonme »

nice! btw, wrt the `Memset` function, if you have something like

    func foo(b []byte) {
        for i := range b {
            b[i] = 0
        }
    }
the compiler turns it into a `memclr` call which can be pretty fast: https://github.com/golang/go/commit/f03c9202c43e0abb13066985...

Perhaps there could be a performance boost to a simple for-range loop if `value == 0`?

Post reply on HN