Jump to page: 1 2
Thread overview
Kernel in D
May 31, 2014
Mineko
May 31, 2014
Kagamin
May 31, 2014
Qox
Jun 04, 2014
Kagamin
May 31, 2014
Adam D. Ruppe
May 31, 2014
ed
Jun 05, 2014
1100110
Jun 05, 2014
1100110
Jun 05, 2014
ed
May 31, 2014
Qox
Jun 01, 2014
Adam D. Ruppe
May 31, 2014
So, I've gotten interested in kernel programming in D.. And as much as I like C/C++, I wanna try innovating, I'm aware that phobos/gc and any OS-specific issues are going to be a problem, but I'm willing to implement them into the kernel itself.

So, I guess what I'm asking is this: What should I look out for, what should I avoid, and what should I use to my advantage?

I'm not expecting this kernel to be Linux right off the bat, but I would like to see how far D can go with this.

Any ideas? :P
May 31, 2014
http://www.xomb.org/ ?
May 31, 2014
On Saturday, 31 May 2014 at 07:28:32 UTC, Mineko wrote:
> Any ideas? :P

Buy my book, chapter 11 talks about it a little to get you started :P

http://www.packtpub.com/discover-advantages-of-programming-in-d-cookbook/book


The summary of my approach there is:

1) Use a regular linux compiler and a custom linker script to make an ELF executable, I wouldn't worry about making a cross compiler or anything fancy like that.

2) Use GRUB or qemu -kernel to boot that executable. No need to write your own bootloader.

3) Compile without the runtime, instead using a minimal object.d, here's a fairly simple one for example: http://arsdnet.net/dcode/bare/object.d or a more complete one can be found in here: http://arsdnet.net/dcode/minimal.zip

4) Add back features from teh real druntime as needed, but I say avoid those that are too hard to do memory management manually (so like just leave array concatenation unimplemented, instead write a regular struct that owns its own memory and has append methods and use it)

5) Love inline asm and naked functions for interrupt handlers

6) Pay attention to struct alignment (also see chapter 7 of my book if you decide to go that route) when defining hardware layouts!

7) Don't try to use TLS variables, always use __gshared on module level or static variables cuz tls won't actually work.



That should get you started to play around!
May 31, 2014
On Saturday, 31 May 2014 at 07:28:32 UTC, Mineko wrote:
> So, I've gotten interested in kernel programming in D.. And as much as I like C/C++, I wanna try innovating, I'm aware that phobos/gc and any OS-specific issues are going to be a problem, but I'm willing to implement them into the kernel itself.
>
> So, I guess what I'm asking is this: What should I look out for, what should I avoid, and what should I use to my advantage?
>
> I'm not expecting this kernel to be Linux right off the bat, but I would like to see how far D can go with this.
>
> Any ideas? :P

I wrote a little kernel a while back that all started when I read this wiki page:

http://wiki.osdev.org/D_Bare_Bones

You may be beyond this already as it is pretty basic stuff...still it's good if you're just learning like I am. There are some articles that helped me fix the 64-bit bootloader issues I was having as well.

Cheers,
ed

May 31, 2014
You should definitly use templating and CTFE for your advantage.
For example you could use the (compile time) component based design to design (heap) allocators after a at cmpile time known configuration. The possibilities of templating and compile time code gen are enormous.

Instead of using "real" OOP classes you should use the object bound functions (you have functions which take as a first argument the struct or a ref of a struct, just look it up in the documentation for the functions).
This allows to use OOP without writing a GC.

Furthermore, all kind of array ops need GC.

If you want exception handling it could be a small problem. Even a "simple" scope expression

> scope(exit) foo();

uses exception handling in the background.
It could be possible to diassemble the *.obj/*.o file, change all entries which use __except_list to something else.
Basically you need to rewrite *** [fs: __except_list] to something else which doesn't use fs, maybe you can get away with using a global scratch memory, i've not done any experiments tho.

Inovation with D is allways a good thing :)

---

For the building of the kernel i used gdc, together with a ld linkscript and some other magic (a python script which grabs some stuff from a disambled file or modified something, dunno). Today gdc is outdated, so i would choose ldc or dmd (ldc for better speed, but its not that important in the beginning).
May 31, 2014
On Saturday, 31 May 2014 at 07:57:18 UTC, Kagamin wrote:
> http://www.xomb.org/ ?

seems to be outdated, but its another OS written in D.
June 01, 2014
On Saturday, 31 May 2014 at 22:54:48 UTC, Qox wrote:
>> scope(exit) foo();
>
> uses exception handling in the background.

That just works with dmd even in the bare metal environmnet.

Throwing an exception needs library support with dmd but you can copy/paste it from druntime - I did that in my minimal.zip.
June 04, 2014
On Saturday, 31 May 2014 at 23:27:45 UTC, Qox wrote:
> On Saturday, 31 May 2014 at 07:57:18 UTC, Kagamin wrote:
>> http://www.xomb.org/ ?
>
> seems to be outdated, but its another OS written in D.

It's dead for only a year, the developer have probably graduated.
June 05, 2014
On 5/31/14, 7:57, ed wrote:
> On Saturday, 31 May 2014 at 07:28:32 UTC, Mineko wrote:
>> So, I've gotten interested in kernel programming in D.. And as much as
>> I like C/C++, I wanna try innovating, I'm aware that phobos/gc and any
>> OS-specific issues are going to be a problem, but I'm willing to
>> implement them into the kernel itself.
>>
>> So, I guess what I'm asking is this: What should I look out for, what
>> should I avoid, and what should I use to my advantage?
>>
>> I'm not expecting this kernel to be Linux right off the bat, but I
>> would like to see how far D can go with this.
>>
>> Any ideas? :P
>
> I wrote a little kernel a while back that all started when I read this
> wiki page:
>
> http://wiki.osdev.org/D_Bare_Bones
>
> You may be beyond this already as it is pretty basic stuff...still it's
> good if you're just learning like I am. There are some articles that
> helped me fix the 64-bit bootloader issues I was having as well.
>
> Cheers,
> ed
>

Just a warning, there are a few bugs on that wiki page.  Nothing major, just don't expect every example to work out of the box. (unless it has been  updated in the last year of course).

I thought about editing it, but I lost interest in my project before I got around to it. =C

I've long since forgotten what issues I encountered though...
June 05, 2014
On 6/5/14, 6:05, 1100110 wrote:
> On 5/31/14, 7:57, ed wrote:
>> On Saturday, 31 May 2014 at 07:28:32 UTC, Mineko wrote:
>>> So, I've gotten interested in kernel programming in D.. And as much as
>>> I like C/C++, I wanna try innovating, I'm aware that phobos/gc and any
>>> OS-specific issues are going to be a problem, but I'm willing to
>>> implement them into the kernel itself.
>>>
>>> So, I guess what I'm asking is this: What should I look out for, what
>>> should I avoid, and what should I use to my advantage?
>>>
>>> I'm not expecting this kernel to be Linux right off the bat, but I
>>> would like to see how far D can go with this.
>>>
>>> Any ideas? :P
>>
>> I wrote a little kernel a while back that all started when I read this
>> wiki page:
>>
>> http://wiki.osdev.org/D_Bare_Bones
>>
>> You may be beyond this already as it is pretty basic stuff...still it's
>> good if you're just learning like I am. There are some articles that
>> helped me fix the 64-bit bootloader issues I was having as well.
>>
>> Cheers,
>> ed
>>
>
> Just a warning, there are a few bugs on that wiki page.  Nothing major,
> just don't expect every example to work out of the box. (unless it has
> been  updated in the last year of course).
>
> I thought about editing it, but I lost interest in my project before I
> got around to it. =C
>
> I've long since forgotten what issues I encountered though...


I should also clarify that I'm just a novice and really just wanted insight into how it all worked.  So anyone more experienced might simply know something that I did not.
« First   ‹ Prev
1 2