From owner-freebsd-smp Wed Jul 16 15:36:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA14707 for smp-outgoing; Wed, 16 Jul 1997 15:36:40 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA14696 for ; Wed, 16 Jul 1997 15:36:36 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.5/8.8.5) id RAA22434; Wed, 16 Jul 1997 17:35:39 -0500 (EST) From: "John S. Dyson" Message-Id: <199707162235.RAA22434@dyson.iquest.net> Subject: Re: self modifying kernel code In-Reply-To: <199707162146.PAA10070@Ilsa.StevesCafe.com> from Steve Passe at "Jul 16, 97 03:46:29 pm" To: smp@csn.net (Steve Passe) Date: Wed, 16 Jul 1997 17:35:39 -0500 (EST) Cc: terry@lambert.org, smp@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hi, > > > > I see the possible usefullness for "self-modifying-code" in several places in > > > the SMP kernel. > > > > [ ... discussion of patch vectors vs. indirected jump tables ... ] > > > Comments? > > > > Are we assuming that the processors will be Pentium only? The icache > > is not written back prior to the P5. This takes a significant number > > of NOP's to flush the pipeline (as discussed in Van Guilluwe's "The > > Undocumented PC" in the section where he investigates instruction cache > > depth using self-modifying code). > > > > Note that these patches would have to be done for 386/486 in the UP case. > > interesting point. we decided along time ago that supporting 486/SMP > was not going to happen. There is very little if any such legacy hardware > left, and I doubt you could by such a thing anymore. > IMO only --- There never was that much of the 486/SMP stuff anyway, relatively so. Let's move and look forward, without breaking things much for existing user base. We currently have NO 486/SMP user base, and IMO, our efforts are best placed on things moving us into the future, not the 1980s :-). John