Received: (from major@localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA13020
	for pups-liszt; Thu, 18 Feb 1999 03:32:46 +1100 (EST)
Received: from moe.2bsd.com (0@MOE.2BSD.COM [206.139.202.200])
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id DAA13014
	for <pups@minnie.cs.adfa.oz.au>; Thu, 18 Feb 1999 03:32:36 +1100 (EST)
Received: (from sms@localhost)
	by moe.2bsd.com (8.9.0/8.9.0) id IAA02404;
	Wed, 17 Feb 1999 08:32:00 -0800 (PST)
Date: Wed, 17 Feb 1999 08:32:00 -0800 (PST)
From: "Steven M. Schultz" <sms@moe.2bsd.com>
Message-Id: <199902171632.IAA02404@moe.2bsd.com>
To: entropy@zippy.bernstein.com, pups@minnie.cs.adfa.oz.au
Subject: Re: 2.11BSD, non-split i/d issues
Sender: owner-pups@minnie.cs.adfa.edu.au
Precedence: bulk

Hi -

> From: maximum entropy <entropy@zippy.bernstein.com>
> I would prefer to use 2.11BSD because I understand it's still actively
> used, and not as buggy as 2.9.  But everything I've read about 2.11BSD
> says that it needs split i/d to run.  Can anyone give me more detail
> about this?  Was support for machines without split i/d removed from
> the kernel, or is it just that some of the programs are too big to fit
> in a single 64k segment?

	Oh, support was NOT removed.  Non-split executables (magic number
	0407 and 0410) will still run.  

	The kernel will not fit - without split I/D it is impossible to
	create a /unix image that fits within a single 64kb (actually 48kb
	since the kernel stack takes 1 segment and the 'u' area takes
	another) address space.

	I actually went thru the exercise once (2.10 era) of creating a bare 
	bones kernel that would fit in - at least the linker said it would.
	That was only done by ripping out lots of stuff - no networking, no
	statistics gathering, almost no drivers, etc.  Never 'ran' it though
	since there seemed to be little point in such a stripped down system.

	Even V7 was hard pressed to run on a non-split machine!  In fact there
	was a paper written about shoehorning V7 onto an 11/40 and the hoops
	that needed to be jumped thru.  Not sure but that document might be
	in the /usr/doc tree of one of the PUPS Distributions hierarchy.

	Steven

