From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <e01c1aafa710d7af0edd26169e7988d7@plan9.bell-labs.com>
Date: Sun, 30 Oct 2005 17:56:54 -0500
From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 386
In-Reply-To: <9ab217670510301315n3ac47987l@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: a2c099ca-ead0-11e9-9d60-3106f5b1d025

Sorry, I rounded the effect down. You get to remove the
following from the kernel if you drop the 386:

	{ 3,	-1,	32,	"386", },	/* family defaults */
and 
	if(X86FAMILY(m->cpuidax) == 3)
		conf.copymode = 1;

and to simplify this:

		if(read && conf.copymode == 0 && s->ref == 1) {

but you get to add code to check and whine if you try to
run the kernel on a 386.

On Sun Oct 30 16:16:32 EST 2005, devon.odell@gmail.com wrote:
> 2005/10/30, jmk@plan9.bell-labs.com <jmk@plan9.bell-labs.com>:
> > On Sun Oct 30 15:34:52 EST 2005, devon.odell@gmail.com wrote:
> > > ...
> > > My understanding of how this got into the embedded chipset stuff was
> > > that a suggestion was made to deprecate 486 as well, which I don't
> > > think we should do at all. Get rid of 386, support 486+.
> > > ...
> >
> > If you keep the 486 then there is no point in removing the 386,
> > you would gain nothing.
> 
> Huh? I thought we would gain the use of the page invalidation instruction?