From owner-freebsd-current  Fri Dec  6 21:49:26 1996
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id VAA11020
          for current-outgoing; Fri, 6 Dec 1996 21:49:26 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id VAA10971
          for <current@FreeBSD.org>; Fri, 6 Dec 1996 21:49:20 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id QAA16647; Sat, 7 Dec 1996 16:43:55 +1100
Date: Sat, 7 Dec 1996 16:43:55 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199612070543.QAA16647@godzilla.zeta.org.au>
To: bde@zeta.org.au, toor@dyson.iquest.net
Subject: Re: 3.0-current Kernel panicking on bootup
Cc: current@FreeBSD.org, dyson@dyson.iquest.net, markm@iafrica.com
Sender: owner-current@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

>In the case of the other code in the system (incl VM system), we are
>stuck with the earlier processors' legacy.  When it is a good idea,
>we can come up with unique solutions for each type of backwards
>compatibility need.  If there is an efficient general way of doing things,
>I cannot think of it...

Dynamic linking.  This is practical for LKMs: determine the
characteristics of the system at boot time and recompile some LKMs to
optimize them for the current system if anything has changed.

Bruce