From owner-freebsd-current@FreeBSD.ORG Thu Jul 22 13:06:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8821016A4CE; Thu, 22 Jul 2004 13:06:03 +0000 (GMT) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EDED43D1F; Thu, 22 Jul 2004 13:06:03 +0000 (GMT) (envelope-from marks@dell-laptop.6bone.nl) Received: by postman.ripe.net (Postfix, from userid 8) id 6E85A4E32B; Thu, 22 Jul 2004 15:06:02 +0200 (CEST) Received: from birch.ripe.net (birch.ripe.net [193.0.1.96]) by postman.ripe.net (Postfix) with ESMTP id 2D4D84E25C; Thu, 22 Jul 2004 15:06:02 +0200 (CEST) Received: from dell-laptop.6bone.nl (cow.ripe.net [193.0.1.239]) by birch.ripe.net (8.12.10/8.11.6) with SMTP id i6MD624c017249; Thu, 22 Jul 2004 15:06:02 +0200 Received: (nullmailer pid 6722 invoked by uid 1001); Thu, 22 Jul 2004 13:06:01 -0000 Date: Thu, 22 Jul 2004 15:06:01 +0200 From: Mark Santcroos To: Robert Watson Message-ID: <20040722130601.GA2751@laptop.6bone.nl> References: <40FE8F81.7040409@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Handles: MS6-6BONE, MS18417-RIPE X-RIPE-Spam-Level: X-RIPE-Spam-Status: N 0.021436 / 0.0 / 0.0 / disabled X-RIPE-Signature: 8e89a2dabd2545582b43ba63ad8fd93c cc: "freebsd -current@" Subject: Re: vmnet.ko missing - but it's there! - vmware and crashes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2004 13:06:03 -0000 On Wed, Jul 21, 2004 at 12:01:40PM -0400, Robert Watson wrote: > I've been wondering if we shouldn't bring the VMware modules into the base > source tree for some time -- the license is probably an issue Bringing it simply in the base tree is indeed not an option. What I think that we need is mechanism to connect 3rd party modules to the build. So that when the kernel is rebuild, the 3rd party modules are rebuild too. Of course there is a change that the module won't compile, but we should create a mechanism then where we can disable that module easily until the port gets updated too. IMHO the most important point to reach is that it can't happen anymore that we load an out-of-sync vmware module at boot time and panic. It should either be correctly rebuild or not installed at all (and removed). Mark