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...