64 Bit D Kernel

Brian Madden untwisted at gmail.com
Thu Oct 25 09:10:44 PDT 2007


Alexander Panek wrote:
> Jarrett Billingsley wrote:
>> "Alexander Panek" <a.panek at brainsware.org> wrote in message 
>> news:ffk3sd$2is7$1 at digitalmars.com...
>>> Brian Madden wrote:
>>>> As of right now our code is sort of all over the place, and fairly 
>>>> undocumented, but we're mostly groping in the dark right now.  If 
>>>> anyone has questions or comments, feel free to voice them.
>>> I hope there'll be some more documentation, soon. I don't know how 
>>> you guys communicate during development, but e.g. a public mailing 
>>> list/newsgroup/forum would be tremendously cool to track down your 
>>> design/implementation decisions and such (doesn't really make sense 
>>> if you're sitting next to each other, communicating vocally, of course).
>>
>> Usually we communicate with our mouths.  Texts, IMing, and vulgar hand 
>> signals are our other main channels of communication.  ;)
> 
> That's great! Be sure to keep a Stik around.
> 
>>> Ad comments..mhm.. I got a few questions, if you don't mind :)
>>>
>>> - Did you guys try to make the build process work with DSSS entirely?
>>
>> We've got a pretty involved build process, and not many files yet.  I 
>> don't think DSSS would be of much use at least until a later stage.
> 
> As of now, you seem to use a Makefile; building with DSSS would be more 
> interesting in terms of "proof of concept", etc. I tend to try to keep a 
> project sticking to its languages'(or language's) tools, which would be 
> DSSS in case of D, respectively Make in case of C or assembly (though 
> you can do that one file with DSSS, too :P).
> 
>>> - Where there approaches to get rid of assembly and/or C?
>>
>> There are no C files left.  I think the only (non-inline) assembly 
>> left is boot.S, which is called by GRUB and sets up the stack, initial 
>> GDT, and initial page table and makes the jump to 64-bit mode.  After 
>> that, it's all D with some inline assembly here and there (thank you 
>> GDC's extended ASM syntax).
> 
> Right..you jump into the cold water (64bit) right there, missed that.
> 
>> I have no idea if we plan on moving this to any other architecture.
> 
> Hehe, maybe you should at least /plan/ to, so you have a code base that 
> allows it....
> 
>>> - Why exokernel? Why not micro?
>  >
>> I defer to James for that argument :S
> 
> ...but apparently James knows more about this in particular. :)

The short answer to this is that we really like the exokernel idea, and 
in prior research has been shown to significantly increase the speed of 
applications.

The long answer is that we're really in to the idea of using/writing 
pluggable libOSes.  It'd have a huge (positive) impact on research, as 
well as system performance.  Since libOSes are found in userland rather 
than in the kernel there is less trapping (less context switching), and 
more stability (even if the libOS dies it doesn't mean the system dies). 
  The kernel itself is very small and only performs protection, not 
abstraction.  This protection, not abstraction idea gives developers a 
wider range of access possibilities.  Since we're not abstracting, 
someone could write code that is highly optimized for the hardware using 
direct access, or they could write code that makes system calls to 
libOSes that handle the hardware access for them.

James wrote up a little manifesto that you can read here: 
http://wiki.pittgeeks.org/index.php?title=Why_an_exokernel%3F that 
explains everything with a bit more depth. :)

> 
> Personally, I am planning on splitting up my kernel into a completely 
> platform dependant (the nucleus), and a mostly independant (the actual 
> kernel) part. Basically, the nucleus implements a specific interface for 
> all sorts of memory operations (allocating, sharing, moving, as well as 
> paging and other rather platform specific [from an implementation point 
> of view] things) and maybe additionally the base of IPC, as long as the 
> platform has some support for it, that might speed up things.
> 
> The rest should be implemented "generic" enough to keep the code base 
> platform independent. If this independency isn't feasable, this 
> particular piece of code should be put into a module, rather than 
> "polluting" the kernel package(s).

Thats not a bad idea, and I'm pretty sure that without really talking 
about it, we had intended to do this already.  The boot code we're 
working with right now is x86_64 specific, but once we start on the 
kernel's protection mechanisms we'll keep things generic enough that it 
can be shoved on top of different boot code and just work.

> 
> Best regards,
> Alex



More information about the Digitalmars-d mailing list