From owner-freebsd-current Tue Apr 1 20:57:22 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id UAA05578 for current-outgoing; Tue, 1 Apr 1997 20:57:22 -0800 (PST) Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA05573 for ; Tue, 1 Apr 1997 20:57:20 -0800 (PST) Received: from fakir.india.hp.com (fakir.india.hp.com [15.10.40.3]) by palrel1.hp.com with ESMTP (8.7.5/8.7.3) id UAA06216; Tue, 1 Apr 1997 20:57:05 -0800 (PST) Received: from localhost by fakir.india.hp.com with SMTP (1.37.109.20/15.5+ECS 3.3) id AA134058855; Wed, 2 Apr 1997 10:27:35 +0500 Message-Id: <199704020527.AA134058855@fakir.india.hp.com> To: "Justin T. Gibbs" Cc: freebsd-current@freebsd.org Subject: Re: Kernel Module System In-Reply-To: Your message of "Tue, 01 Apr 1997 21:18:47 MST." <199704020420.VAA18373@pluto.plutotech.com> Date: Wed, 02 Apr 1997 10:27:35 +0500 From: "A JOSEPH KOSHY" Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >>>> ""Justin T. Gibbs"" writes Hi, > You don't want a single version number really. You want one for each > subsystem that an LKM may depend upon. For example, the SCSI system might Yes, but there is a tradeoff between complexity and utility. If we basically want to prevent a 2.2 LKM being loaded into a 3.1 kernel, (or vice-versa) a simple version number would suffice. This would trap say, attempts by a user to load in a third-party LKM into his/her FreeBSD kernel. In the absence of such a mechanism; the user would know that the LKM is mismatched only when something catastrophic happens. This is really a release engineering issue, not a development one, and I think it may make it easier for third party vendors to offer binary only LKM addons for FreeBSD. Such a LKM versioning system is probably not relevant for people following -current; the traditional method of rebuilding LKMs every now and then would probably still suffice for them. I was initially looking a `kernel signature' derived from the sizes of key data structures, version numbers of sources etc. However, further thought showed that such a solution would really be overkill for the intended purpose and a single version number would probably suffice. Koshy My Personal Opinions Only.