From owner-cvs-src@FreeBSD.ORG Tue Aug 3 17:05:43 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD2B216A4CE; Tue, 3 Aug 2004 17:05:43 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B0FA43D2F; Tue, 3 Aug 2004 17:05:43 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (IDENT:brdavis@localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.12.10/8.12.10) with ESMTP id i73H5hOF007071; Tue, 3 Aug 2004 10:05:43 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.12.10/8.12.3/Submit) id i73H5hac007070; Tue, 3 Aug 2004 10:05:43 -0700 Date: Tue, 3 Aug 2004 10:05:43 -0700 From: Brooks Davis To: John Baldwin Message-ID: <20040803170543.GD2037@Odin.AC.HMC.Edu> References: <200408021954.i72JsYD5028875@grimreaper.grondar.org> <410EB74B.7020206@root.org> <200408031239.06942.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="n2Pv11Ogg/Ox8ay5" Content-Disposition: inline In-Reply-To: <200408031239.06942.jhb@FreeBSD.org> User-Agent: Mutt/1.5.4i cc: src-committers@FreeBSD.org cc: Brooks Davis cc: cvs-src@FreeBSD.org cc: David O'Brien cc: cvs-all@FreeBSD.org cc: Mark Murray cc: Nate Lawson Subject: Re: cvs commit: src/sys/modules Makefile X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2004 17:05:43 -0000 --n2Pv11Ogg/Ox8ay5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 03, 2004 at 12:39:06PM -0400, John Baldwin wrote: > On Monday 02 August 2004 05:51 pm, Nate Lawson wrote: > > Mark Murray wrote: > > > Brooks Davis writes: > > >>IMO this is a module system bug not a bug in any given module. There= 's > > >> no good reason for the system to succeed at loading a module that's > > >> already there regardless of how it got there. I don't understand the > > >> module system well enough to know where the bug lies, but I believe = the > > >> DECLARE_MODULE statement provides more then enough information to av= oid > > >> duplicates. > > > > > > I'm looking to see if MODULE_VERSION() may fix this. > > > > The case where mem is compiled into the kernel and then an attempt is > > made to load it as a module needs to be detected by looking for an > > instance of the devclass. See how acpi/legacy co-exist. This is not > > just a problem with the same module being loaded multiple times. >=20 > mem is a dev_t aka struct cdev *, not a device_t. There is no devclass. Similarly, where I've seen this problem is pseudo network interfaces which are nothing but ifnet entries. This is why I think we need to handle this in the module layer and stop requring hack in every driver. I think peter's module code might fix some of this since I think we'll get module registrations for static modules. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --n2Pv11Ogg/Ox8ay5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBD8XmXY6L6fI4GtQRAgduAKCYOhoFYzYA7i3yuwxiy6kWCyFK8wCg2foG 83+tc/LimHpwXfPmTY/aYrk= =hW+w -----END PGP SIGNATURE----- --n2Pv11Ogg/Ox8ay5--