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

[Basile STARYNKEVITCH]

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.