altosdev-kernel

[Altosdev-kernel] Kernel Source Reuse

[Alexey M. <tkt...@cs...>]

Hei,

The interesting idea came to my crazy head this night. Why should we write 
general, simple things? It maybe rather usefull to get ready-to-use kernel 
with sources, which was wrote by another group of developers, and use it 
in own needs?

No, It is bad idea. If you have ideas about OS organization and visual 
representation.. talk about them.. I think, that Danil has a lot of ideas 
about GUI... ;) He has a Mac, as far as I remember.

Kernel Panic can give us several suggestions about kernel structure, 
abilities and implementation.. Hei Kernel, Can you?

Another important thing is to select development instruments; I suggest 
djgpp for kernel compilation and grub for booting.. Does everyone agree?

You can load djgpp from internet and the installation we need gets only 
8M and grub is approx. 1M.

Ok, I feel that no one want to talk here. I decided to set requirements to 
the first workable version of kernel. But we still not decided, who will 
load modules? Who will link them with kernel?

-- 
See you later,
 d.

+358 040 817 8540

Re: [Altosdev-kernel] Kernel Source Reuse

[Kernel P. <rzh...@he...>]

Hello, Alexey Malev.

On Friday, March 08, 2002 at 7:20:14 AM you wrote:

AM> It maybe rather usefull to get ready-to-use kernel with sources,
AM> which was wrote by another group of developers, and use it in own
AM> needs?
Ehh.. I guess we would end up having another Linux clone.. Anyway, do
you know of any implementation of your stream model in any OS? I'm not
familiar with that.. As for me, it's much more interesting to write
everything yourself, of course using some other open source code for
references.. At least you will understand any single line of code
you've written.

AM> Kernel Panic can give us several suggestions about kernel structure,
AM> abilities and implementation.. Hei Kernel, Can you?
I was hoping I wasn't the only one here who could.. ;) Well.. I
suggest doing a microkernel (which implies IPC in form of streams,
e.g.).. That's the general idea =) . If anyone has any more specific
questions/suggestions, post them here..

AM> Another important thing is to select development instruments; I suggest 
AM> djgpp for kernel compilation and grub for booting.. Does everyone agree?
Well, not only DJGPP.. That's just a DOS port of GNU tools.. If anyone
has, say, a Linux box, he/she will use native Linux tools.. I hope
there also exists a Mac port of them. That means, we should be using
GNU tools (not restricted to DJGPP).

As to grub.. I had a different idea, which I've almost implemented as
of now. As we (at least I) would like that the OS can be compatible
with other ones (that is, the user wouldn't have to delete his/her
windows/unix partition to just give it a try), we shouldn't make the
kernel depend on the filesystem/drive type. If you look at FreeBSD or
Linux, they can only boot from their native filesystems, because they
have only ufs/ext2fs support built into the kernel. Which is bad. I
have done this (almost) this way (without grub, but that's not
the point): our bootsector gets loaded by the MBR, it then loads the
filesystem driver, which loads the last-stage loader. The latter uses
the filesystem driver to load the kernel, kernel-mode filesystem
driver, kernel-mode low-level disk driver (as the kernel can't use
BIOS in pm), and links them together. And that's it. I'm currently
doing the linking stage, as it proved the most difficult one. All
other drivers (FAT16, ATA) and the bootsector (FAT16) are done. When
this is done, the kernel will be able to run on virtually any drive
hardware and filesystem, provided that an appropriate driver exists.
This implies doing no changes to the kernel itself. ..I guess, that's
what's called modularity =) . Even at the boot stage..

AM> You can load djgpp from internet and the installation we need gets only 
AM> 8M and grub is approx. 1M.
The problem is, that DJGPP only ships with COFF and AOUT executable
formats built into the binutils. This way, you'll have to rebuild
binutils to enable ELF support. I strongly suggest using ELF as this
is the only most-commonly used executable format which is flexible
and yet simple enough. I've rebuilt binutils 2.11.2 (the latest as of
now) to support ELF, so if anyone is interested I can upload the
executables somewhere so that you can download them.

AM> But we still not decided, who will load modules? Who will link
AM> them with kernel?
What exactly do you mean?

-- 
Regards,
 Kernel Panic                          mailto:rzh...@he...

Re: [Altosdev-kernel] Kernel Source Reuse

[Alexey M. <tkt...@cs...>]

> Hello, Alexey Malev.
Hei, but dozzer sounds better for me..

> AM> It maybe rather usefull to get ready-to-use kernel with sources,
> AM> which was wrote by another group of developers, and use it in own
> AM> needs?
> Ehh.. I guess we would end up having another Linux clone.. Anyway, do
> you know of any implementation of your stream model in any OS? I'm not
> familiar with that.. As for me, it's much more interesting to write
> everything yourself, of course using some other open source code for
> references.. At least you will understand any single line of code
> you've written.
Yap. I meant that we can get kernel with sources and reuse it in the way 
we need, i.e. replace any IPC except signals and add streams. But you are 
right.. it is better to write all from scratch.

> Well, not only DJGPP.. That's just a DOS port of GNU tools.. If anyone
> has, say, a Linux box, he/she will use native Linux tools.. I hope
> there also exists a Mac port of them. That means, we should be using
> GNU tools (not restricted to DJGPP).
Yap. You are right again..

> This implies doing no changes to the kernel itself. ..I guess, that's
> what's called modularity =) . Even at the boot stage..
This is good idea, what did you do in linking phase... how do you link 
modules together?

> AM> You can load djgpp from internet and the installation we need gets only 
> AM> 8M and grub is approx. 1M.
> The problem is, that DJGPP only ships with COFF and AOUT executable
> formats built into the binutils. This way, you'll have to rebuild
> binutils to enable ELF support. I strongly suggest using ELF as this
> is the only most-commonly used executable format which is flexible
> and yet simple enough. I've rebuilt binutils 2.11.2 (the latest as of
> now) to support ELF, so if anyone is interested I can upload the
> executables somewhere so that you can download them.
Ok.. do it for me at least.
 
> AM> But we still not decided, who will load modules? Who will link
> AM> them with kernel?
> What exactly do you mean?
You answered this question above in your letter..

-- 
See you later,
 d.

+358 040 817 8540