-- querying number of adapters
-- querying driver version
-- querying logical drives per adapter
Pretty much useless.
Everything else seems to be passed through black-box from the userspace ioctl right to the card, then the response from the card copied right back to userspace.
So with an open source driver (mostly useless, but it got me this far), closed specs, and closed management utilities, what's next?
I've added printks where ioctls come in, so I can run the closed-source management utilities and see what they're sending. (and receiving, but I haven't done that yet)
strace only gives:
ioctl(0x3, 0xc06e6d00, 0x80ea780) = 0
ioctl(0x3, 0xc06e6d00, 0x80ea780) = 0
ioctl(0x3, 0xc06e6d00, 0x80ea780) = 0
ioctl(0x3, 0xc06e6d00, 0x80ea780) = 0
ioctl(0x3, 0xc06e6d00, 0x80ea780) = 0
ioctl(0x3, 0xc06e6d00, 0x80ea780) = 0
And I'd dump those 0x80ea780 addresses under gdb, except you can't strace something under gdb, and running it under gdb changes the addresses it uses (presumably).
Maybe I could look at /proc/`pidof megamgr.bin`/mem while stracing it? Hadn't thought of that until just now. But the timing's the hard part. The ioctl struct is read/write, so I want to see it both before the kernel messes with it, and after.
So back to my (ugly) kernel hacking. I've got my changes to build now (into *.o files) but I'm trying to figure out how kbuild makes the *.ko files.
