
	(I wasn't planning to announce this for a while, but it seems from
reading comp.os.minix and comp.os.unix.pc-clone.16bit that some people are
already asking about it... :)

	I'm working on Linux/16, a new U*IX clone for 16-bit Intel machines
(8086/8 and 286s).  It's very limited right now, and only does simple
task-switching (although an in-kernel fork is now working).  It simply prints
"ABAB" much like Linus' early experiments :)  It dosen't do anything else yet -
no global memory management, no user processes, etc...

	Right now it uses a hacked Linux boot loader, but I'm hoping to write
a DOS-based boot loader in the next week or two, so that it can be run under
DOS (so I can leach it's fs code and put a UMSDOS layer on it among other
little things like EMS support :)

	(I just posted linux16-0.00.3.1.tar.gz to sunsite.unc.edu:/pub/Linux/
Incoming.  You're all free to look at it, and it's under the GPL.  It's 
definitely a developer's only release though, since there is not much there
yet... you also need to get bcc-linux16.tar.gz, which is a binary and source
distribution of bcc for Linux a.out...) 

	Alan Cox is also doing work on the tree in different areas (IRQ's, 	
printk, and the console drivers).  I haven't seen his source tree yet, but 
he will probably have all that stuff working RSN... (I might put IRQ's on my 
own list soon however...)

	However, this is not the original Linux/ELKS project Alan was working
on (I know Alan's calling his tree Linux/ELKS - so that may be the name 
afterall.  I was calling it Linux/MT after a few early ideas I had, until I
realized I couldn't make the MT stand for anything :)  I'm almost leaning 
towards a non-Linux name for at least the binary package distribution (in my
dreams :) , but I'm not sure what to call it yet... 

	Right now scheduling and forking are in their own tasks.  I don't think
Linux/16 will be a microkernel - they're in different tasks mostly because
of the difficulty in task-switching an 8088 effectively (no TSS's for me :( )
and the fact that from other tasks, registers can be saved from the stack 
easily.  I'll probably fix that soon too, but considering that I already  
debugged the code in there now, I'll probably keep it a low priority.

	(Of course, if someone writes non task-oriented code that works, I'll
put it in... :)

	Also, the Makefiles are somewhat broken - they don't do dependancies
and don't recompile lower-level sources at the top level.  They'd probably
be easy to fix by someone who knows how to do makefiles right :)

	I think discussion should be kept to comp.os.unix.pc-clone.16bit for
now - it's a low traffic general group from what I can tell and would
be a good one to use if it's still active everywhere.  If there's enough demand,
I could also try to get a list at vger.rutgers.edu as well...

	That's about it (except for some notes I typed in here while working
on the announcement.)  Anyone who is interested in working on it can e-mail
me at page0588@sundance.sjsu.edu... although it'll take a bit of time to
develop a framework for patches, releases, etc... 

	Enjoy!

	- Chad


---
 
	Most of what I'm going to write about now are just ideas on where I 
want Linux/16 to go in some key areas.  I'm sorry I don't have code for all of 
this yet, but I don't have enough time in the day to do all this... :)

	Right now I'm working on the stubs for the memory management layer, 
which is intended to be highly adaptable (at least for lower-end platforms)  
My first target is standard 8086 real mode, and then adding garbage collection
so that the heap will be quite efficent (as long as it's kept to small-model
programs, I figure that we can mess with cs, ds, and ss all we want :)

	(It's based highly around the Windoze Global Heap model - which isn't
as bad as it sounds, since it's actually pretty clean when it comes to
small model programs... :)

	The next mm code will be for EMS (probably 4.0).  This MMS will use
EMS 4.0 calls to switch processes in and out of the real mode memory space...
they will actually be running out of EMS memory, so we more or less get a
virtual memory system.  I was thinking of a DPMI system, but that would be 
limited in all cases to the BIOS driver package, which would make multitasking
difficult to do right. 

	A concept which I've also come up with is stack shadowing+protection.
The idea is to copy the stack into the top 64K of RAM, where any stack over-run
cannot break the system.  This will slow things down, so it'll be implemented
as a command-line option.  (I expect the EMS version to do this automagically
with no speed penalty over standard task-switching.) 

	In addition, I'm planning to have code modules which are callable 
(and registerable) through a syscall interface of sorts.  This will make
it possible to have both shared libraries and kernel modules at the same
time.  I expect it to be rather crude at first (passing tables of exported
functions around), but I think it will become easier after tools are written
and the executable format modified slightly...

	No drivers have been written yet... Soon after MMS is up, I plan 
to write the driver interfaces and the BIOS Driver Package (which should be
two mid-size C/asm files which contain standard keyboard, fd, hd, and serial
drivers...)  This will work until things get pretty good in other areas, when
we'll hit a wall due to the fact that all of our fs code, etc. is practically
single-threaded...

	In that vein, the fs code will probably be built on int 0x21 calls
at first (yes, I'm planning to leech DOS.  I know I run the risk of having
this all called Lindoze, but it's the easiest way for now :)  It won't be
so bad after we port the UMSDOS layer over though... after VFS and the buffer
cache are developed, we can get MINIX and (U)MSDOS in the kernel properly, or
at least make them code modules. 

	I don't know *what* the syscall layer will look like yet.  Alan has
mentioned that he would like it to be Minix compatible (as would many people
on comp.os.minix for that matter, I assume :) - but I don't know enough about
it yet, and I'm not even sure binary compatibilty is a Good Thing, but I'll
welcome patches for it if someone (Alan or someone else) comes up with them... 

	My concept is to have a basic structure which the syscall layers can
handle, then have seperate syscall structures based on that with the info 
needed to carry it out.  I'm expecting there not to be a full task switch
when a system call is done - the cs and ds will probably change, while it
uses memcpy calls provided by MMS to do the actual structure copying...  

	I'm not sure how much of a speed penalty all this stuff is going to
incurr... it could be little, or it could be a lot in some cases.  I don't
really want to sacrifice core functionality for speed (no fs tasks which 
happen to double as system call layers for me :)  Hopefully it'll be fast
enough to support 2-5 users on an XT without major problems...
	
 
