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

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

> 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