DLKM load/unload question(s) - HP UX

This is a discussion on DLKM load/unload question(s) - HP UX ; 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: DLKM load/unload question(s)

  1. 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
    http://www.sackheads.org/mayfield email: mayfield+usenet@sackheads.org
    My mail provider does not welcome UCE -- http://www.sackheads.org/uce


  2. Re: DLKM load/unload question(s)

    Jimmie Mayfield wrote:

    > 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?


    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

  3. Re: DLKM load/unload question(s)

    On Fri, 05 Aug 2005 08:59:23 GMT, Pai wrote:
    > Jimmie Mayfield wrote:
    >
    >> 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?


    Thanks for the response!

    > 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.


    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.

    > 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.


    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


  4. Re: DLKM load/unload question(s)

    >>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.

    >
    >
    > 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?


    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.

    >
    > 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.
    >


    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.


    > 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).
    >


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

    --vishwas

+ Reply to Thread