Is this a good or a bad idea?

[Synon]

I had an idea (I want to write a bunch of little tools, mostly Perl scripts and such to ease writing my kernel later on (in a year or two)) yesterday which Linux users will recognise because it's based off the vmlinuz idea (the Linux kernel is built into vmlinux and then compressing into vmlinuz (because, let's face it: the Linux kernel is bloated with bells and whistles)).

I don't know how similar or otherwise this is to the vmlinuz process, because I don't know how they do it (I have built a Linux kernel, but all I did was

Code: Select all

make menuconfig; make; make modules; make install; make modules_install [failed]; yaird [Yet Another mkInitRD] [failed];

, I couldn't build the modules or the initrd, so I never got it to boot); but anyway, here it is in the form of a 65-line C comment (I wrote it with C syntax highlighting because I wanted it coloured in).

I haven't come up with an official name yet (I'll do that later); but I like the name Prolix (pun on Minix, Prolix is an actual word meaning "verbose;" I've been told multiple times that I over-comment my code) so I'll use that for now (and maybe forever).

Code: Select all

/* Kernel build process:
 * **** List: ****
 *    * Kernel is built into prolixkernel.bin (binary)
 *    * Clzss (C implementation of the LZSS compression algorithm) is called
 *      to create prolixkernel.zbin (zipped binary)
 *    * Cmd5 (C implementation of the MD5 hashing algorithm) is called to
 *      create an md5 hash of the kernel.
 *    * The resulting hash is built into the file prolixboot.bin, via a #define 
 *      passed by gcc on the command-line
 *    * On boot, the prolixboot.bin program re-md5's the prolixkernel.zbin file
 *      and checks that it's the same as the #defined md5 (I'll build Clzss and
 *      Cmd5 into the prolixboot.bin program) and then either prints a warning
 *      message that the kernel was tainted or extracts it, depending on whether
 *      the md5s were different or the same, respectively.
 *    * The prolixkernel boots
 *
 * **** Flow Chart: ****
 *
 * Key:
 *    ( ... ): start or end of block
 *    [ ... ]: processing
 *    / ... /: input/output
 *    < ... >: conditional
 *    ->, <-, V or ^: control flow (right, left, down and up respectively).
 *
 * **** Building: ****
 *
 * ( start build process ) <---------------
 *    V                                   ^
 * < kernel built? > NO -> [ build kernel ]
 *    YES
 *    V
 * / file prolixkernel.bin is created /
 *    V
 * [ lzss-compress the kernel with Clzss ]
 *    V
 * / file prolixkernel.zbin is created /
 *    V
 * [ md5sum the kernel with Cmd5 ]
 *    V
 * [ build prolixboot.bin from boot.o Cmd5.o and Clzss.o,
 *   pass the md5 hash on the command line as KERNEL_MD5 ]
 *    V
 * / file prolixboot.bin is created /
 *    V
 * [ create floppy disk image ]
 *    V
 * / file prolix.img is created /
 * ( end build process )
 *
 * **** Booting: ****
 *
 * ( start boot process )
 *    V
 * [ re-MD5 the prolixkernel.zbin file with Cmd5 ]
 *    V
 * < new MD5 matches KERNEL_MD5? > NO -> ( print error message and shut down )
 *    YES
 *    V
 * [ de-compress the kernel with Clzss ]
 *    V
 * [ boot the kernel ]
 *    V
 * ( end boot process )
 */

If you can read it, I made a flow chart in the hope of making the process easier to understand in-depth; but I don't know how comprehensible the flowchart actually is, so hopefully the bulleted list should be enough.

[-m32]

I think you should focus on writing a kernel. Worry about how to package it later. As far as I know, Linus didn't even go this far for his first Linux release

[Synon]

I think you should focus on writing a kernel. Worry about how to package it later. As far as I know, Linus didn't even go this far for his first Linux release

Well, I don't have the experience to do so right now (just under a year in C and I've been learning asm since about September); so I thought that I would make it all a bit easier by learning everything I need to (I'm reading the wiki; it's very good, but could probably use more on hard disk IO) and getting a bunch of stuff set up. I just thought that at some point, the kernel is going to start getting bigger and bigger; so if I have all the tools I need already there, I can focus more on writing the kernel instead of having to write all these tools from scratch. I can just modify them where necessary.

And you're right; I've looked at Linux 0.01 and it was very simplistic. IIRC the only tools he wrote at that stage were build scripts, makefiles, etc. Now, they have ncurses, Gtk and Qt menus for configuring which parts of the kernels you want to build; which tell you what each option does, sometimes the effects on the size of the kernel of selecting it, and sometimes recommends you a selection (one option says "You definitely want this").

[~]

I am doing the same thing, but with COM files for DOS.

In this way I can interact with the hardware and actually see how it reacts, inspect the registers and other stuff as part of the COM module, then I can arrange properly the COM modules I have made and call them from a BAT program. It seems to be much easier than coding a program several times until it contains the correct sequence of operations for a task.

I also make programs, but only when I know that I have enough experience to code it properly and portably.

It's much better to do things in this way, because a single "atomic" module that works right and that can be later combined with other "bug-free" modules worths much more than several failed kernel attempts spanning years of experience without good code to store.

No matter how small is a tool or snippet. If it works exactly as it should and is portable such that it can later be integrated without really rewriting it, it's something significative.

Not to mention that trying to write a kernel at the first learning stages will consume your enthusiasm more and more each time you think you have to rewrite it, knowing that you must code yet again code for something you were already working in several times, but got completely trashed. It's much more fun and rewarding watching small code gems combined doing tasks with the hardware (or in a more advanced stage, with software algorithms), slowly but stably. Even if you have to rewrite something, you lose practically nothing, and you are gaining more useful source code each time you write, say, a snippet that does nothing more than read one or more very specific I/O Ports, etc.

[Synon]

I am doing the same thing, but with COM files for DOS.

In this way I can interact with the hardware and actually see how it reacts, inspect the registers and other stuff as part of the COM module, then I can arrange properly the COM modules I have made and call them from a BAT program. It seems to be much easier than coding a program several times until it contains the correct sequence of operations for a task.

I also make programs, but only when I know that I have enough experience to code it properly and portably.

It's much better to do things in this way, because a single "atomic" module that works right and that can be later combined with other "bug-free" modules worths much more than several failed kernel attempts spanning years of experience without good code to store.

No matter how small is a tool or snippet. If it works exactly as it should and is portable such that it can later be integrated without really rewriting it, it's something significative.

Not to mention that trying to write a kernel at the first learning stages will consume your enthusiasm more and more each time you think you have to rewrite it, knowing that you must code yet again code for something you were already working in several times, but got completely trashed. It's much more fun and rewarding watching small code gems combined doing tasks with the hardware (or in a more advanced stage, with software algorithms), slowly but stably. Even if you have to rewrite something, you lose practically nothing, and you are gaining more useful source code each time you write, say, a snippet that does nothing more than read one or more very specific I/O Ports, etc.

That's a really good idea, the DOS thing. Didn't DOS run everything in kernel space? Because I remember a guy I met on a programming forum saying that's sort of what he was doing; gradually taking over from DOS until he doesn't need the DOS kernel any more, and he has his own. Or something like that, anyway.

[Owen]

Effectively, yes. DOS runs in "Real mode", aka "1979 processor backwards compatibility mode", which has no protection (So all programs can access all hardware), but, being from 1979, can only address 1MB of RAM, and somewhat awkwardly at that.

[~]

Yes, but since we are working our way beyond DOS and using Unreal Mode, it shouldn't be too much of a worry; the DOS platform can be used to interactively use the command prompt to do what we want without having to write it ourselves or fully booting and rebooting a "test kernel" every time we want to test some minor thing.

Javascript can also be used to write a variety of tests without using a compiled or "complicated" language platform like C for things for which the only thing that matter are to see if the concepts work in practice and also starting to build a functional code logic.