From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 29 13:50:46 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 21F9C1065675 for ; Thu, 29 Dec 2011 13:50:46 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id D9C508FC14 for ; Thu, 29 Dec 2011 13:50:45 +0000 (UTC) Received: by iadj38 with SMTP id j38so29907306iad.13 for ; Thu, 29 Dec 2011 05:50:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=DRG86oExDruJssVMvAUyLUCqi0Ps2rrbVwF6scJx4Ik=; b=SgSYxWcZpyq5TEY8aMdBaNAE1vqjHgofD7AoLBA/hChZlVKjV4SZiN4H+xFNMsEah7 RfcUvmpohu7S06Da8CT8OIpZ4DMzMNJ0Cj431x5+72Jne67QJksDduToIOvU88/TEMZv VoWGmVVdw0ACmOrs3P1+oZIFqJJ1M1TKFWLzo= Received: by 10.50.155.195 with SMTP id vy3mr40683300igb.12.1325166645321; Thu, 29 Dec 2011 05:50:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.207.7 with HTTP; Thu, 29 Dec 2011 05:50:14 -0800 (PST) In-Reply-To: <20111229133516.GJ50300@deviant.kiev.zoral.com.ua> References: <20111228135641.GV50300@deviant.kiev.zoral.com.ua> <20111228150023.GY50300@deviant.kiev.zoral.com.ua> <20111229120333.GI50300@deviant.kiev.zoral.com.ua> <20111229133516.GJ50300@deviant.kiev.zoral.com.ua> From: Chris Rees Date: Thu, 29 Dec 2011 13:50:14 +0000 Message-ID: To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 13:50:46 -0000 2011/12/29 Kostik Belousov : > On Thu, Dec 29, 2011 at 12:53:19PM +0000, Chris Rees wrote: >> 2011/12/29 Kostik Belousov : >> > 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? = =A0I could >> >> >> >> >> even check for /dev/sndstat, though that doesn't seem elegan= t to me... >> >> >> >> > >> >> >> >> > kldstat -v, but really /dev/sndstat seems simpler and just as= effective. >> >> >> >> > >> >> >> >> >> >> >> >> 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 load= ed is >> >> >> > papering over some issue. >> >> >> >> >> >> True, although I figured that it was a simple conflict, possibly t= o do >> >> >> with sndstat. >> >> >> >> >> >> Also, I'm getting panics with the following patch, whether sound i= s >> >> >> loaded or not :) >> >> >> >> >> >> + =A0if (modfind("sound") >=3D 0) >> >> >> + =A0 =A0{ >> >> >> + =A0 =A0 =A0cmn_err (CE_WARN, "A conflicting sound driver is alre= ady loaded"); >> >> >> + =A0 =A0 =A0return EBUSY; >> >> >> + =A0 =A0} >> >> >> + >> >> >> >> >> >> Is there a better way to handle such conflicts? >> >> > >> >> > You have missed the point. There is some bug in oss driver that cau= sing >> >> > the panic. Presumed 'conflict' cannot cause the harm itself, beside= s not >> >> > allowing second driver to attach to the same device, and should not= result >> >> > in panic. Trying to implement a half-measure that only covers the p= roblem >> >> > you do a mis-service. >> >> > >> >> > And you still did not provided the panic message. >> >> >> >> I'm sorry, you're right. =A0However, your guess was in fact correct; >> >> make_dev was being called, which returned a null pointer because it >> >> failed. >> >> >> >> 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. >> >> >> >> Since this solves the panic and anyone should be able to work out fro= m >> >> the warning message what the problem is, AND this is a port that >> >> apparently no-one else uses, should this be sufficient? >> >> >> >> 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, AFAI= R. >> > So you get absolutely undeterministic behaviour which driver is refere= nced >> > by devfs node. >> > >> >> Chris >> >> >> >> [1] http://www.bayofrum.net/~crees/patches/oss-patch-kernel-OS-FreeBS= D-os_freebsd.c >> > >> > I highly recommend to return error in case of any make_dev_p(9) failur= e, and >> > not only EEXIST. >> >> That'd be great-- but I can't work out how to do it :( >> >> Do I need to return a different value? > > =A0 =A0 =A0 =A0error =3D make_dev_p(); > =A0 =A0 =A0 =A0if (error !=3D 0) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("Error creating device node /dev/%s= : %d\n", name, error); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return (error); > =A0 =A0 =A0 =A0} > No, that's what I wanted. Thank you. Chris