Device driver: wsio_get_isc() returns NULL - HP UX

This is a discussion on Device driver: wsio_get_isc() returns NULL - HP UX ; Hello. I'm writing a monolithic DKLM and I'm finding that wsio_get_isc() always seems to return a NULL 'isc' pointer even though the return code indicates success. For example, on the driver_ioctl() entry point: mydriver_ioctl(dev_t dev, int flag) { struct isc_table_type ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Device driver: wsio_get_isc() returns NULL

  1. Device driver: wsio_get_isc() returns NULL


    Hello. I'm writing a monolithic DKLM and I'm finding that wsio_get_isc()
    always seems to return a NULL 'isc' pointer even though the return code
    indicates success.

    For example, on the driver_ioctl() entry point:

    mydriver_ioctl(dev_t dev, int flag)
    {
    struct isc_table_type *isc;
    ...
    rc = wsio_get_isc(dev, &isc, &mydriver_wsio_info);
    if (rc != 1) {
    msg_printf("rc != 1\n");
    return EIO;
    }

    if (!isc) {
    printf("NULL!\n");
    return EIO;
    }
    ...
    }


    Now, section 10.8 of HP's DDK FAQ attempts to explain this problem:

    "The device instance number is supposed to be encoded in bits 16-23
    (ie the third byte)...If the dev_t that is passed down has this encoding,
    wsio_get_isc() will return a valid ISC pointer."


    According to 'ioscan -fun', my device's instance number is 0:
    unknown 0 10/6/3/0 mydrv CLAIMED INTERFACE PCI Co-Processor

    This agrees with the character special file I created in /dev:
    crw-rw-rw- 1 root sys 254, 0 Aug 18 21:17 my_device

    Furthermore, it agrees with the dev_t that's being passed to my ioctl()
    routine: fe000000 (major 254, minor 0x000000).

    (It is interesting that ioscan does not report /dev/my_device. Is that
    indicative of a problem? If so, what?)

    So...I don't understand. The kernel is forming a dev_t value and passing it
    to my ioctl() routine (or open(), or close()). However when I attempt to use
    WSIO to get an isc pointer from that dev_t value, the returned pointer
    is NULL. The FAQ implies that this is because the dev_t value was somehow
    invalid.

    What am I not understanding here?

    Any insights would be greatly appreciated. Thanks.


    Jimmie


    (Sorry about the long-winded post. I've wasted a day pursing this problem
    and I feel I'm no closer to the answer now than I was when I started. As
    an aside, I have to admit driver development for Solaris and in fact Linux
    is a lot less frustrating than it has been for HP-UX. There's so little
    useful HP-UX information available that it seems HP is trying to discourage
    driver developers from targetting their platform).



  2. Re: Device driver: wsio_get_isc() returns NULL

    Jimmie Mayfield wrote:
    > Hello. I'm writing a monolithic DKLM and I'm finding that wsio_get_isc()
    > always seems to return a NULL 'isc' pointer even though the return code
    > indicates success.
    >
    > For example, on the driver_ioctl() entry point:
    >
    > mydriver_ioctl(dev_t dev, int flag)
    > {
    > struct isc_table_type *isc;
    > ...
    > rc = wsio_get_isc(dev, &isc, &mydriver_wsio_info);
    > if (rc != 1) {
    > msg_printf("rc != 1\n");
    > return EIO;
    > }
    >
    > if (!isc) {
    > printf("NULL!\n");
    > return EIO;
    > }
    > ...
    > }
    >
    >
    > Now, section 10.8 of HP's DDK FAQ attempts to explain this problem:
    >
    > "The device instance number is supposed to be encoded in bits 16-23
    > (ie the third byte)...If the dev_t that is passed down has this encoding,
    > wsio_get_isc() will return a valid ISC pointer."
    >
    >
    > According to 'ioscan -fun', my device's instance number is 0:
    > unknown 0 10/6/3/0 mydrv CLAIMED INTERFACE PCI Co-Processor
    >
    > This agrees with the character special file I created in /dev:
    > crw-rw-rw- 1 root sys 254, 0 Aug 18 21:17 my_device
    >
    > Furthermore, it agrees with the dev_t that's being passed to my ioctl()
    > routine: fe000000 (major 254, minor 0x000000).
    >
    > (It is interesting that ioscan does not report /dev/my_device. Is that
    > indicative of a problem? If so, what?)
    >
    > So...I don't understand. The kernel is forming a dev_t value and passing it
    > to my ioctl() routine (or open(), or close()). However when I attempt to use
    > WSIO to get an isc pointer from that dev_t value, the returned pointer
    > is NULL. The FAQ implies that this is because the dev_t value was somehow
    > invalid.
    >


    1> Could you post your drv_info_t initialization here ?

    2> Try calling wsio_get_isc(dev, &isc, NULL) with wsio.h included.
    This will work only if your driver is char driver.

    --vishwas

  3. Re: Device driver: wsio_get_isc() returns NULL

    > That leads to another question though:
    >
    > 1) What is the significance of the classname in the drv_info_t structure?
    >
    > The DLKM appeared to get initialized properly even with the bad
    > classname string. That is, the attach() function was called, the 'isc'
    > was claimed and I was able to use that isc to read and write the
    > card's register space. No errors were reported by WSIO or any other
    > kernel routine.
    >
    > Problems didn't occur until I started to do things from user space.
    > The kernel called my driver routines (open, close, ioctl, etc) when the
    > user space app accessed the corresponding /dev entry which suggests that
    > the kernel has properly mapped the device major to my driver. But the
    > bad classname string somehow caused the kernel to fail to map the dev_t
    > to the isc. This still confuses me.
    >
    > It seems to me that if the classname were such an crucial piece
    > of information, WSIO should have thrown an error as soon as my driver
    > tried to claim the isc in the attach() routine.
    >


    AFAIK class should be one of the known class strings or unknown.
    Yes, WSIO should have reported an error if the class was not
    acceptable.

    --vishwas

+ Reply to Thread