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