a Kernel Usable for Tunes - ideas, questions, and code...

[Ashley Winters]

On Tue, 21 Jul 1998, Basile STARYNKEVITCH wrote:
> 
> Hello All,
> 
> ((I posted a message from home <basile.starynkevitch@wanadoo.fr> but
> apparently something went wrong, probably on my home Linux PC!!))
> 
> On
> "http://perso.wanadoo.fr/starynkevitch/basile/kut_0_0.tgz"
> 
> you will find a first pre-alpha (it compiles & links but doesn't run)
> Kernel Usable for Tunes or kut.

Hmm... I'll look through it...

> I'm waiting for comments
> 
> -- file KUT/doc.txt
> rcsid $Id: doc.txt,v 0.1 1998/07/19 20:26:31 basile Exp $
> 
> Some ideas regarding KUT (Kernel Usable for Tunes) - I maybe should
> have called it TUK for Tunes Kernel
> 
> (Several ideas are actually from Faré <rideau@ens.fr> which whom I meet)
> 
> overall goal:
> 
> make a self-hoisted bootable system, runnable on ordinary ix86/PC, to
> permit TUNES development. Target platform has at least 32Mb RAM (cheap
> today!), an IDE/ATAPI disk (with at least 200Mb free in a dedidacted
> KUT partition), an SVGA screen (and runs Linux!)
> 
> This system is aimed exclusively towards Tunes developpers, not
> towards ordinary users. 
> 
> KUT is developped on a Linux platform. The boot loader is GRUB
> http://www.uruk.org/grub/
> 
> BIOS (or Lilo or other loader) loads GRUB which switch into 32 bit
> mode and loads KUT.
> 
> KUT runs (only) in 32 bits ring 0 (supervisor) mode, without
> pagination. 

Is that a design choice or have you not gotten around to it? Pagination
is very useful, even with Tunes. I believe that Tunes should not only
demand-page load objects, but should also be able to swap ram to disk
without needing to persistently store full-fledged objects on-disk.

> I don't expect to use TSS (task system segments).

Well, Tunes should take advantage of TSS's when hosting violently
abusive operating-systems.

> In a certain way, KUT is less than a plain 32 bits DOS.
> 
> * two important issues:
> 
> A) how to communicate with Linux? I assume I have only one PC (and I
>   don't want to run Tunes under or with Linux, although this is
>   debatable). [[not every TUNES developper can afford 2 PCs]]
>   essentially, this means sharing some disk stuff with both Linux &
>   KUT.
> 
>    I'm not really decided between 2 alternatives:
> 
>    1) using an available Linux filesystem, and code it into
>       KUT. ext2fs is way too complex for such a task. I might consider
>       Minix. A variant could be coding a KUT specific filesystem
>       module loadable by a recent (Linux2.0.35 ou 2.1.108) kernel.
> 
>    2) writing a sort of KUT filesystem, and write a program (Linux
>       user mode) which can read,write,& check this filesystem.

     3) creating a file on a filesystem, and using an index of the
	disk sectors to be used as your persistent store.

Option 3 allows development on Windos and Linux and wherever while
allowing painless uninstall.

> B) how to program KUT. The main goal is to have KUT very rapidly self
> hoisted, and able to program TUNES. I think that I have to define a
> specific Scheme dialect (perhaps with a very different
> syntax). Basically, I mean a simple Scheme (eg like SIOD) with
>    * some very basic module system
>    * no macros
>    * almost no I/O (no files) - only keyboard & disk.
> 
> Tunes assembler stuff (the c86 assembler nearly written in Scheme) is
> IMHO the top priority. Then writing the core memory managemetn in
> Tunes assembly+ Scheme and writing a kind of editor/debugger (in Scheme).

Sounds good. I have my own ideas about code assembly, but yours sounds
nice...

> KUT should handle interrupts, and have low level keyboard & disk
> drivers (no netwxork yet).
> 
> BIOS should not be used. Too difficult in 32 bits mode!

Yeah. That's what GRUB is supposed to help us avoid...

> The KUT kernel should probably contain a bytecode interpreted tuned
> for Scheme (or Tunes first langage). I think that a bytecode
> interperter is easier to write than anything else. So we need a
> cross-compiler to produce the first bytecode programs.

Hmm... what would be bytecoded? Shouldn't we be starting Tunes off with
compiled machine-code? We low-level people should spend our time on
bootstrapping a compiler in KUT (or TUK). A bootstrapped high-level
language compiler will not go to waste no matter what language we base
it on.

Ashley Winters

> I need a lot of hints, advices, and encouragments to help me.
> 
> july 19, 1998
> 
> Basile STARYNKEVITCH - 8 rue de la Faiencerie, 92340 BOURG LA REINE (France)
> tel 01.46.65.45.53. mél = basile point starynkevitch at wanadoo point fr
> boulot=work= basile point starynkevitch at cea point fr