Structs and Pointers

<< Prev: Wait Queues       Next: Calling C++ From C >>

Next I went to actually try to implement the macro to replace a wait_queue_head_t with an IOLock.

That seemed pretty straightforward:

#define wait_queue_head_t  IOLock

Only, it didn't work:

Error:(352, 20) field has incomplete type 'IOLock' (aka '_IOLock')

That didn't make any sense. IOLock was defined right there in IOLocks.h in the OS X SDK:

typedef struct _IOLock IOLock;

OK, so I guess the question is what is struct _IOLock? I couldn't find it.

Well, maybe I should give a little more context:

#ifdef IOLOCKS_INLINE
typedef lck_mtx_t IOLock;
#else
typedef struct _IOLock IOLock;
#endif /* IOLOCKS_INLINE */

So maybe instead the IOLOCKS_INLINE wasn't set right?

I banged my head against the wall for quite a while, looking for that blasted _IOLock, before I went back and looked at where I had used an IOLock previously:

IOLock *firmwareLoadLock;

There was one key difference there -- that little star.

So I tried:

#define wait_queue_head_t  IOLock *

And what do you know? Problem solved.

So my conclusion here is that struct _IOLock isn't defined in the IOKit header files, the "client API". But you can create a pointer to one, so long as you treat it as opaque. So long as you don't try to go ahead and use any specific fields or otherwise interact with it. That's OK here, because all I do is pass it to other API calls (IOLockLock and etc.), and their implementation functions (which presumably have access to the _IOLock definition) can do the dirty work.

Still, it caused me quite a bit of confusion that you could create a pointer to a thing while not being able to create the thing itself -- and that an API client should just expect that.

Now I know.

<< Prev: Wait Queues       Next: Calling C++ From C >>