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

[Maneesh Yadav]

OK, I was lost a long time ago when dave started to talk about all that meta
lambada calculus stuff... I am actually very interested in formal theory but I was
begining get the feeling of way too much abstractness..while you guys have been
talking I've been working on a 386 exokernel..it boots initalizes timers has the
logic for multiprocessing (I still have to get an SMP system to get the actualy
code tested...), HD driver running and I will have a FAT system up and running
soon... I realize I haven't been very active on the mailing list it's just that I
felt I couldn't contribute...if you guys are interested in using this as a base
lemme know...what's with all the hardware req's?...we don't even know what TUNES
looks like running, yet.  If you want a bit of a write up again tell me and I will
post.

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.
>
> 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. I don't expect to use TSS (task system segments). 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.
>
>   I probably prefer the 2nd way. Key idea might be writing a disk
>   fragment allocator. a disk fragment is 1 to 64 consecutive disk
>   sectors [512bytes each]. Essentially, this means writing a disk
>   sector garbage collector. Perhaps almost no file name or directories
>   (maybe only one root fixed length directory is enough). But files
>   might contain other file pointers. Essentially, do for the disk what
>   a simple allocator+garbage collector do for memory. So a file is a
>   disk objects, made of other file pointers and plain data.
>
> 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).
>
> 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!
>
> keyboard driver should
>
>   have a non hand-crafted keyboard map. [[keyboard map is a Linux
>   keyboard map, compiled into the kernel. Not everyone have a US
>   keyboard. I have a French Latin1 azertyuiop (not Qwerty) keyboard.]]
>
>   translate raw keyboard events into sort of keysyms
>
>   define some magic keys for low level debugging...
>
> disk driver should
>
>   read IDE disk (no SCSI).
>
>   handle a primary partition, and find a KUT partition in it.
>
>   be able to read non KUT (eg DOS or Linux) partitions but don't write
>   in them.
>
> 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.
>
> 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
>
> N.B. Any opinions expressed here are onely mine, and not of my organization.
> N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.
>
> ---------------------------------------------------------------------
> Basile STARYNKEVITCH   ----  Commissariat à l Energie Atomique
> DRN/DMT/SYSCO * CEA/Saclay bat.460 * 91191 GIF/YVETTE CEDEX * France
> fax: (33) 1,69.08.96.96; phone: 1,69.08.40.66; home: 1,46.65.45.53
> email: Basile point Starynkevitch at cea point fr
> I speak french, english, russian. Je parle français, anglais, russe.
>
> Pursuant to USC 47, there is a $500 per incident charge for each
> and every piece of Unsolicited Commercial Email (UCE) sent to this or
> any of my other addresses.  Sending UCE's to any of my addresses
> implies general acceptance of these terms.
>