From owner-freebsd-smp Wed Jul 16 14:48:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA11148 for smp-outgoing; Wed, 16 Jul 1997 14:48:06 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA11071; Wed, 16 Jul 1997 14:47:55 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id PAA10070; Wed, 16 Jul 1997 15:46:29 -0600 (MDT) Message-Id: <199707162146.PAA10070@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: Terry Lambert cc: smp@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: self modifying kernel code In-reply-to: Your message of "Wed, 16 Jul 1997 14:41:26 PDT." <199707162141.OAA01599@phaeton.artisoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 16 Jul 1997 15:46:29 -0600 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. so it could be #ifdef'd in such a way as to NOT happen on SMP + 486 easily enough. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD