Suitable for OS kernels?

[Frank]

I'd be interested in your definition of "systems programming
language."

In my mind one of the criteria for that definition is that the
language is suitable for developing an operating system kernel. I see
some features that would make me question whether Go would work well
for that task, e.g. the inclusion of garbage collection.

Thanks,
FM

Frank W. Miller

[John Cowan]

Frank scripsit:

> In my mind one of the criteria for that definition is that the
> language is suitable for developing an operating system kernel. I see
> some features that would make me question whether Go would work well
> for that task, e.g. the inclusion of garbage collection.

Kernel programming is embedded programming, not systems programming.

--
My corporate data's a mess! John Cowan
It's all semi-structured, no less. http://www.ccil.org/~cowan
But I'll be carefree co...@ccil.org
Using XSLT
On an XML DBMS.

[Scott Mansell]

The first issue would be the large runtime.

You need to have it fully operational before you can run one line of go code. But thats not a huge issue, because there are kernels written in c++ and microsoft made Singularity which is programmed in C#.

Then runtime would need to be re-written now that its not running on top of an OS.

Also, the lack of the ability to embed asm code would complicate things but It should be possible.

But the most important question is: Would it a good idea in the first place?
____________
Scott Mansell

[Russ Cox]

I think it would be a lot of fun to write an operating system
in Go, probably without garbage collection.

Russ

[merimus]

>
> Kernel programming is embedded programming, not systems programming.
>

no, systems programming is kernels, compilers, debuggers, etc...
embedded programming is essentially for computers which have specific
functions, ie: not general purpose computers.

A systems programming language has to be able to tightly control
memory layout and access hardware devices... go does not appear to be
suitable for that.

[Charles Forsyth]

"no, systems programming is kernels, compilers, debuggers, etc...

...

A systems programming language has to be able to tightly control
memory layout and access hardware devices "

this seems a little contradictory: for instance, it has been a long
time since any compiler
or debugger i've written (which i would consider systems programming)
has needed
either to "tightly control memory layout" or "access hardware devices"
(except in the usual ways, via an operating system).

[merimus]

> this seems a little contradictory: for instance, it has been a long
> time since any compiler
> or debugger i've written (which i would consider systems programming)
> has needed
> either to "tightly control memory layout" or "access hardware devices"
> (except in the usual ways, via an operating system).

Well... to use a compiler to write a device driver you have to be able
to deal with the memory accesses, specific hardware addresses, and
lots of bit twiddling. (those operating system services you are
using had to be written using something). You also have to remember
that all this came from back in the day when you didn't necessarily
have a compiler to begin with. Ahhh... the good old days :)

most embedded programming is systems programming, but not all systems
programming is embedded.

[Ian Lance Taylor]

merimus <mer...@gmail.com> writes:

> A systems programming language has to be able to tightly control
> memory layout and access hardware devices... go does not appear to be
> suitable for that.

Go does have those capabilities via the unsafe package. But I won't
stress the point. I don't expect to see many kernels written in Go
any time so.

Ian

[Ben Leslie]

Operating systems kernels probably not, but device drivers would be nice.

The unsafe package sounds intriguing :)

There was mention of disabling the GC, is this an option? Or rather,
how much hacking of the code would be required to turn off GC?

Thanks,

Benno

[Ian Lance Taylor]

Ben Leslie <ben.l...@gmail.com> writes:

> There was mention of disabling the GC, is this an option? Or rather,
> how much hacking of the code would be required to turn off GC?

Disabling GC today would be fairly easy, but as we beef it up and move
more into the compiler it will take more work to turn it off. But I
expect Russ will keep that in mind as he does the work.

Ian

[Rob 'Commander' Pike]

On Nov 12, 2009, at 8:51 PM, Ben Leslie wrote:

> The unsafe package sounds intriguing :)

It's not only unsafe, it's unpleasant, but it has its place. Very
few packages should ever need its facilities, but if you're talking
device drivers I can see it happening.


It would be very easy to turn off the garbage collector at the
moment. It might get harder later unless the compilers take an option
to disable some of the code they'll be generating to support the next
generation collector.

-rob

[Frank]

Interesting that you could turn off garbage collection. I didn't
notice in the spec anything allowing explicit freeing of memory, like
a free() or dispose construct. I'll assume that because the language
assumes gc or else I just missed it ;) Seems like that construct
would be necessary if you wanted to turn off gc.

This is a great discussion and did answer my question. I'll be making
a distinction in the future between "systems" and "operating systems
kernel" programming. C still appears to be the right solution for the
latter.

I would add in passing that the "feel" of Go seems to me like Limbo
with very clean string handling. This makes sense given the pedigree
of the developers and the fact that Google is paying for its
development and Google servers do just a small amount of string
processing...

Thanks,
FM

[Ben Leslie]

On Sat, Nov 14, 2009 at 1:22 AM, Frank <ma...@frankwmiller.net> wrote:
>
>
> Interesting that you could turn off garbage collection.  I didn't
> notice in the spec anything allowing explicit freeing of memory, like
> a free() or dispose construct.  I'll assume that because the language
> assumes gc or else I just missed it  ;)  Seems like that construct
> would be necessary if you wanted to turn off gc.
>
> This is a great discussion and did answer my question.  I'll be making
> a distinction in the future between "systems" and "operating systems
> kernel" programming.  C still appears to be the right solution for the
> latter.

Yeah, I think C (and assembler) is still the tool of choice for
programming operating systems kernels.

Of course in OS designs where the kernel represents only a small part
of the operating system, Go seems, on the surface, like a useful
language for implementing other OS services.

That said, there is definitely scope (IMHO) for a better OS kernel
language, but to be honest I'm not sure the investment would be worth
it.

Cheers,

Benno

[ford]

I have just started a project that aims to create a Linux distribution
that uses Go for everything except for the Kernel (obviously since it
is a Linux distribution). I figured this would be a good way to learn
Go. So far, I have been unable to find documentation for how I would
interface with the Linux kernel from Go.

The main reasons I chose not to write a kernel are:
Garbage collection in Go would complicate things,
lack of the ability to embed ASM (afaik),
I am still learning Go,
my knowledge of C is very rudimentary

On Nov 13, 4:43 pm, Ben Leslie <ben.les...@gmail.com> wrote:

> On Sat, Nov 14, 2009 at 1:22 AM, Frank <m...@frankwmiller.net> wrote:
>
> > Interesting that you could turn off garbage collection.  I didn't
> > notice in the spec anything allowing explicit freeing of memory, like
> > a free() or dispose construct.  I'll assume that because the language
> > assumes gc or else I just missed it  ;)  Seems like that construct
> > would be necessary if you wanted to turn off gc.
>
> > This is a great discussion and did answer my question.  I'll be making
> > a distinction in the future between "systems" and "operating systems
> >kernel" programming.  C still appears to be the right solution for the
> > latter.
>
> Yeah, I think C (and assembler) is still the tool of choice for
> programming operating systems kernels.
>

> Of course in OS designs where thekernelrepresents only a small part

[Devon H. O'Dell]

2009/11/24 ford <brad...@gmail.com>:

> I have just started a project that aims to create a Linux distribution
> that uses Go for everything except for the Kernel (obviously since it
> is a Linux distribution). I figured this would be a good way to learn
> Go. So far, I have been unable to find documentation for how I would
> interface with the Linux kernel from Go.

The interfaces are in src/pkg/syscall.

> The main reasons I chose not to write a kernel are:
> Garbage collection in Go would complicate things,
> lack of the ability to embed ASM (afaik),
> I am still learning Go,
> my knowledge of C is very rudimentary

You wouldn't need to embed assembler, nor would you need to know C.
You would need to link your binary to the proper address, and you
would need to have some way to do some pre-setup for the Go runtime,
which may or may not require C.

--dho

[ford]

Wow. Thank you very much. I know must seem a bit dumb, but I am still
a novice. I will be learning.

On Nov 24, 1:43 pm, "Devon H. O'Dell" <devon.od...@gmail.com> wrote:
> 2009/11/24 ford <bradm...@gmail.com>:

[Uriel]

On Tue, Nov 24, 2009 at 7:31 PM, ford <brad...@gmail.com> wrote:
> I have just started a project that aims to create a Linux distribution
> that uses Go for everything except for the Kernel (obviously since it
> is a Linux distribution). I figured this would be a good way to learn
> Go. So far, I have been unable to find documentation for how I would
> interface with the Linux kernel from Go.
>
> The main reasons I chose not to write a kernel are:
> Garbage collection in Go would complicate things,
> lack of the ability to embed ASM (afaik),

Yea, because nobody would ever write a kernel without inline
assembler! Plan 9 must be some kind of hoax. And Unix? Just a myth.

uriel

[ford]

well, if you are not using ASM, how do you get machine specific
instructions when needed?

On Nov 24, 2:24 pm, Uriel <ur...@berlinblue.org> wrote:

[Ben Leslie]

On Wed, Nov 25, 2009 at 6:50 AM, ford <brad...@gmail.com> wrote:
> well, if you are not using ASM, how do you get machine specific
> instructions when needed?

Well, you are going to need _some_ ASM, but you often write those
directly in assembler and produce object files against which the rest of
the code (written in C), links.

Of course, there is still usually somethings where a call to an external
function is more overhead than you might want to pay, and then inline
assembler and/or compiler intrinsics are usually used.

Hope that helps,

Benno