Joachim Worringen wrote:
> Garrett D'Amore wrote:
>
>> To address that concern, there are at least three different approaches:
>>
>> 1) use a layered driver open (see ldi_open_xxx) and keep D's /dev entry
>> open from A while in use.
>>
>> 2) use a ddi-forceattach and ddi-no-autodetach properties in D's
>> driver.conf file.
>>
>
> Tried #2 as a quick solution and added these two lines to
> /usr/kernel/drv/dis_irm.conf (the driver is /usr/kernel/drv/amd64/dis_irm):
> "
> ddi-forceattach=1;
> ddi-no-autodetach=1;
> "
>
> This works, thanks. Will try #1 lateron.
>
> Two follow-up questions:
> - This only worked after I rebooted (driver was then loaded and
> attached), but not after I changed dis_irm.conf and then loaded the
> driver module manually. This is expected behaviour?
>
Dunno. I would have thought update_drv() would be sufficient. Maybe not.
> - I noted that once a minute, _fini() of this driver is called, but
> mod_remove() then fails with EBUSY. This is probably o.k. and expected?
> (no problem for me).
>
Yes. You are probably running a debug kernel, which periodically tries
to reap kernel modules. If you run a non-debug kernel then you won't
see this behavior.
The _fini() tries to detach your driver, but passes in a flag indicating
that this is in response to "auto-detach", which the DDI intercepts and
now (thanks to the new property) rejects (without ever calling your
driver's detach routine).
You should still be able to manually do modunload -i <major number> to
unload your driver manually.
-- Garrett
> Joachim
> _______________________________________________
> opensolaris-code mailing list
> opensolaris-code@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
