2011/12/29 Kostik Belousov <kostik...@gmail.com>:
> On Thu, Dec 29, 2011 at 12:53:19PM +0000, Chris Rees wrote:
>> 2011/12/29 Kostik Belousov <kostik...@gmail.com>:
>> > On Thu, Dec 29, 2011 at 11:46:57AM +0000, Chris Rees wrote:
>> >> 2011/12/28 Kostik Belousov <kostik...@gmail.com>:
>> >> > On Wed, Dec 28, 2011 at 02:53:42PM +0000, Chris Rees wrote:
>> >> >> 2011/12/28 Kostik Belousov <kostik...@gmail.com>:
>> >> >> > On Wed, Dec 28, 2011 at 12:23:58PM +0000, Chris Rees wrote:
>> >> >> >> On 28 December 2011 12:21, Daniel O'Connor <docon...@gsoft.com.au>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> > On 28/12/2011, at 22:07, Chris Rees wrote:
>> >> >> >> >> Is there a simple way to check for existence of a driver? I
>> >> >> >> >> could
>> >> >> >> >> even check for /dev/sndstat, though that doesn't seem elegant 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 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 :)
>> >> >>
>> >> >> + if (modfind("sound") >= 0)
>> >> >> + {
>> >> >> + cmn_err (CE_WARN, "A conflicting sound driver is already
>> >> >> loaded");
>> >> >> + return EBUSY;
>> >> >> + }
>> >> >> +
>> >> >>
>> >> >> 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
>> >> > result
>> >> > in panic. Trying to implement a half-measure that only covers the
>> >> > problem
>> >> > you do a mis-service.
>> >> >
>> >> > And you still did not provided the panic message.
>> >>
>> >> 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.
>> >>
>> >> 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 from
>> >> 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, AFAIR.
>> > So you get absolutely undeterministic behaviour which driver is referenced
>> > by devfs node.
>> >
>> >> Chris
>> >>
>> >> [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.
>>
>> That'd be great-- but I can't work out how to do it :(
>>
>> Do I need to return a different value?
>
> error = make_dev_p();
> if (error != 0) {
> printf("Error creating device node /dev/%s: %d\n", name,
> error);
> return (error);
> }
>
No, that's what I wanted. Thank you.
Chris
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
