DLKM load/unload question(s)

Hello. I've been tasked with porting a device driver from Solaris to HPUX 11i.
I've created pseudo class drivers under HPUX before but never an interface /
monolithic driver so at present I'm playing with a skeleton driver and I'm
seeing some odd behavior with respect to attach() when loading and unloading
the DLKM.

At the bottom are the relevant pieces of the skeleton driver code.

When the driver is initially configured (config -M mydriver -u), I see the
driver gets loaded, the _attach() method gets called and the driver is
unloaded.

Example syslog output:

enter mydriver_load
leave mydriver_load
enter mydriver_attach
Found a device!
leave mydriver_attach
enter mydriver_if_init
leave mydriver_if_init
10/6/3/0 mydriver
enter mydriver_unload
leave mydriver_unload

After that, when the driver is loaded (either via "kmadmin -L mydriver" or by
simply accessing the /dev entry and letting the kernel demand-load it), I never
see the _attach() method get called. This is a problem because it implies that
interrupts are never going to be set up and device initialization is not going
to occur.

example syslog output following a kmadmin -L mydriver:

enter mydriver_load
leave mydriver_load

Is the kernel somehow assuming that since attach() was called when the config
command was executed that it doesn't need to call attach() again (even though
unload() was called and, thus, the driver should have cleaned-up and freed any
resources it allocated)? Is there something missing in mydriver_unload()
that's causing this behavior?

The HP DLKM documentation for 11i is pretty sparse and HP's DDK doesn't appear
to provide any example DLKM interface/monolithic driver code.

Any advice welcome. Thanks.


Jimmie


---- begin relevant mydriver code ----

static int mydriver_load(void *arg)
{
...
msg_printf("enter mydriver_load\n");
mydriver_wsio_info.drv_info = (drv_info_t *)arg;
rc = wsio_install_driver(&mydriver_wsio_info);
if (!rc) {
msg_printf("wsio_install_driver failed\n");
return ENXIO;
}

rc = mod_wsio_attach_list_add(MOD_WSIO_PCI, mydriver_attach);
if (rc) {
msg_printf("mod_wsio_attach_list_add failed\n");
return ENXIO;
}
msg_printf("leave mydriver_load\n");
return 0;
}

static int mydriver_unload(void *arg)
{
...
msg_printf("enter mydriver_unload\n");

rc = mod_wsio_attach_list_remove(MOD_WSIO_PCI, mydriver_attach);
if (rc) {
printf("mod_wsio_attach_list_remove failed\n");
return ENXIO;
}

rc = wsio_uninstall_driver(&mydriver_wsio_info);
if (rc) {
msg_printf("wsio_uninstall_driver failed\n");
return ENXIO;
}
msg_printf("leave mydriver_unload\n");
return 0;
}


static int mydriver_attach(uint32_t id, struct isc_table_type *isc)
{
msg_printf("enter mydriver_attach\n");

if (id == MYDEVICE_ID) {
msg_printf("Found a device!\n");
isc->gfsw->init = mydriver_if_init;
isc->gfsw->diag = NULL
isc_claim(isc, &mydriver_wsio_info);
}

msg_printf("leave mydriver_attach\n");
return 0;
}

---- end relevant mydriver code ----


--
Jimmie Mayfield
[url]http://www.sackheads.org/mayfield[/url] email: mayfield+usenet@sackheads.org
My mail provider does not welcome UCE -- [url]http://www.sackheads.org/uce[/url]

Jimmie Mayfield wrote:
[color=blue]
> Is the kernel somehow assuming that since attach() was called when the config
> command was executed that it doesn't need to call attach() again (even though
> unload() was called and, thus, the driver should have cleaned-up and freed any
> resources it allocated)? Is there something missing in mydriver_unload()
> that's causing this behavior?[/color]

Two things:

1> ATTACH routine is expected to call the saved attached (head
of the attach chain) routine (i.e. it is not supposed to
call return). I am not sure if this is compulsory for a DLKM.

2> isc_unclaim(isc, &mydriver_wsio_info) has to be called in
you DLKM unload - else I guess one will see the behavior
as you are seeing now.

As you have already unloaded the module - you will have to reboot
the system before you want to try the unload with isc_unclaim()
added.

HTH --vishwas

On Fri, 05 Aug 2005 08:59:23 GMT, Pai <noman@noland.com> wrote:[color=blue]
> Jimmie Mayfield wrote:
>[color=green]
>> Is the kernel somehow assuming that since attach() was called when the config
>> command was executed that it doesn't need to call attach() again (even though
>> unload() was called and, thus, the driver should have cleaned-up and freed any
>> resources it allocated)? Is there something missing in mydriver_unload()
>> that's causing this behavior?[/color][/color]

Thanks for the response!
[color=blue]
> Two things:
>
> 1> ATTACH routine is expected to call the saved attached (head
> of the attach chain) routine (i.e. it is not supposed to
> call return). I am not sure if this is compulsory for a DLKM.[/color]

Actually, this is an area where DLKMs differ from statically-linked
modules. The attach chain doesn't exist for DLKMs (because it would be
impossible to dynamically unload a module once a subsequent driver
has saved a pointer to your attach() routine). So HP has included a
pair of kludge calls: mod_wsio_attach_list_[add|delete] and, so far
as I can tell, relies on the kernel itself to walk the DLKM attach list
calling each attach() function in the list.
[color=blue]
> 2> isc_unclaim(isc, &mydriver_wsio_info) has to be called in
> you DLKM unload - else I guess one will see the behavior
> as you are seeing now.[/color]

I wondered about the existance of an isc_unclaim() function. I do not
see such a beast in the header files nor any mention in HP's DDG or DDR.
At least for 11i. Maybe this routine was added to subsequent versions?


Another observation:

It seems that if I invoke 'ioscan' after performing 'kmadmin -L' then my
driver's attach() method DOES get called. This solves my problem at least
for now but it does raise a couple other questions:

1) Is this the way HP intended for things to work? If so, it would have been
helpful if the DDG/DDR documentation had mentioned it.

2) It seems that this works for manual loading but won't work for
demand-loading where the kernel automatically loads a driver when an app
opens the corresponding /dev node. Is there a configuration flag either
in a DLKM or somewhere in /etc which tells the kernel to do the
equivilant of an 'ioscan' after loading a driver?

The drv_info_t structure has a DRV_SCAN flag but it has no effect
(I suspect it's used for ext_bus class devices).


Again, thanks for the response.

Jimmie

>>2> isc_unclaim(isc, &mydriver_wsio_info) has to be called in[color=blue][color=green]
>> you DLKM unload - else I guess one will see the behavior
>> as you are seeing now.[/color]
>
>
> I wondered about the existance of an isc_unclaim() function. I do not
> see such a beast in the header files nor any mention in HP's DDG or DDR.
> At least for 11i. Maybe this routine was added to subsequent versions?[/color]

Yes, you are right. There is no formal mention of isc_unclaim() in
11i DDG/DDR. But they have used isc_unclaim() in one of the examples,
but without much explanation. But nm(1) on /stand/vmunix does show
the existence of isc_unclaim() in my 11.11 64 bit kernel.
[color=blue]
>
> Another observation:
>
> It seems that if I invoke 'ioscan' after performing 'kmadmin -L' then my
> driver's attach() method DOES get called. This solves my problem at least
> for now but it does raise a couple other questions:
>
> 1) Is this the way HP intended for things to work? If so, it would have been
> helpful if the DDG/DDR documentation had mentioned it.
>[/color]

I have not worked with DLKMs. But I have modified some static drivers
to delay the claim (by having some kernel global variables). At least
in that case you have to run ioscan for the driver to claim the
hardware.

[color=blue]
> 2) It seems that this works for manual loading but won't work for
> demand-loading where the kernel automatically loads a driver when an app
> opens the corresponding /dev node. Is there a configuration flag either
> in a DLKM or somewhere in /etc which tells the kernel to do the
> equivilant of an 'ioscan' after loading a driver?
>
> The drv_info_t structure has a DRV_SCAN flag but it has no effect
> (I suspect it's used for ext_bus class devices).
>[/color]

I don't think DRV_SCAN is for auto load DLKM. Check kmmodreg,modload
, they seem to have some information on this.

--vishwas