From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 29 12:03:39 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1E62106566B for ; Thu, 29 Dec 2011 12:03:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 2C5AA8FC19 for ; Thu, 29 Dec 2011 12:03:38 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pBTC3YOg054046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Dec 2011 14:03:34 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pBTC3X3i017165; Thu, 29 Dec 2011 14:03:33 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pBTC3XBe017164; Thu, 29 Dec 2011 14:03:33 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 29 Dec 2011 14:03:33 +0200 From: Kostik Belousov To: Chris Rees Message-ID: <20111229120333.GI50300@deviant.kiev.zoral.com.ua> References: <20111228135641.GV50300@deviant.kiev.zoral.com.ua> <20111228150023.GY50300@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DBl6kzebMedsdQd1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: hackers@freebsd.org Subject: Re: Checking for other kernel modules on load X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 12:03:39 -0000 --DBl6kzebMedsdQd1 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 29, 2011 at 11:46:57AM +0000, Chris Rees wrote: > 2011/12/28 Kostik Belousov : > > On Wed, Dec 28, 2011 at 02:53:42PM +0000, Chris Rees wrote: > >> 2011/12/28 Kostik Belousov : > >> > On Wed, Dec 28, 2011 at 12:23:58PM +0000, Chris Rees wrote: > >> >> On 28 December 2011 12:21, Daniel O'Connor = wrote: > >> >> > > >> >> > On 28/12/2011, at 22:07, Chris Rees wrote: > >> >> >> Is there a simple way to check for existence of a driver? =9AI c= ould > >> >> >> even check for /dev/sndstat, though that doesn't seem elegant to= me... > >> >> > > >> >> > kldstat -v, but really /dev/sndstat seems simpler and just as eff= ective. > >> >> > > >> >> > >> >> Cheers-- I was thinking of a kernel-level function though. > >> >> > >> >> cognet@ suggested using modfind("sound"), I'll go with that. > >> > Obvious question is what the panic is. Checking for modules loaded is > >> > papering over some issue. > >> > >> True, although I figured that it was a simple conflict, possibly to do > >> with sndstat. > >> > >> Also, I'm getting panics with the following patch, whether sound is > >> loaded or not :) > >> > >> + =9Aif (modfind("sound") >=3D 0) > >> + =9A =9A{ > >> + =9A =9A =9Acmn_err (CE_WARN, "A conflicting sound driver is already = loaded"); > >> + =9A =9A =9Areturn EBUSY; > >> + =9A =9A} > >> + > >> > >> Is there a better way to handle such conflicts? > > > > You have missed the point. There is some bug in oss driver that causing > > the panic. Presumed 'conflict' cannot cause the harm itself, besides not > > allowing second driver to attach to the same device, and should not res= ult > > in panic. Trying to implement a half-measure that only covers the probl= em > > you do a mis-service. > > > > And you still did not provided the panic message. >=20 > I'm sorry, you're right. However, your guess was in fact correct; > make_dev was being called, which returned a null pointer because it > failed. >=20 > The patch at [1] stops the panic, however I was hoping that returning > EBUSY would abort loading the module... At the moment it loads the > module, and doesn't create the sndstat dev, which causes weird errors > with the oss binary commands. >=20 > Since this solves the panic and anyone should be able to work out from > the warning message what the problem is, AND this is a port that > apparently no-one else uses, should this be sufficient? >=20 > BTW, it only affects FreeBSD 9+, couldn't reproduce on my 8.2 dev > machine, but could once I upgraded it. On 8.2, there is no check in the devfs for duplicated cdev names, AFAIR. So you get absolutely undeterministic behaviour which driver is referenced by devfs node. > Chris >=20 > [1] http://www.bayofrum.net/~crees/patches/oss-patch-kernel-OS-FreeBSD-os= _freebsd.c I highly recommend to return error in case of any make_dev_p(9) failure, and not only EEXIST. --DBl6kzebMedsdQd1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk78VxQACgkQC3+MBN1Mb4hDRwCcD1N/Z24y1mPuAnUxAW/XGNPL MBUAoImdr6Z8q8zV/9W0E09grmJENPAZ =gpKx -----END PGP SIGNATURE----- --DBl6kzebMedsdQd1--