tags:

views:

33

answers:

2

I have a nice kernel programming assignment involving a novel kernel locking method, and my group and I have chosen to implement it as a wrapper around a completion. However, the specification requires that we return the number of processes notified by our method, which involved returning the number of processes awoken by complete_all in our implementation.

How do we get that number? It would seem that it is enough to lock the completion with its internal spinlock, count the number of elements, and then unlock it. This method is preempt-safe because our functions are the only ones to have access to the particular completion in question.

So then, the question is: is struct completion opaque? If it is, would it be acceptable to, for the sake of getting our homework done in time for midterm season, ignore that opaqueness? Or, is there a means of doing this without hacks?

+1  A: 

Strictly speaking it's not opaque, ie. it's defined in a header, but you knew that.

It's possible the author would have liked it to be opaque but traded that off for a public definition in order to allow static inlines to operate on it. That's pretty common in kernel code because you're more concerned about speed & code size than a strict API - it's all kernel code after all anyway.

I see:

struct completion {
        unsigned int done;
        wait_queue_head_t wait;
};

So most of the interesting bits are actually in wait_queue_head_t, which is a typedef of struct __wait_queue_head.

The double underscores might indicate the author thinks it's private, or they just thought it would be confusing to have struct wait_queue_head and wait_queue_head_t, ie. the double underscores make it clear you're meant to use the typedef.

I think though you're looking at it the wrong way. You said you need to know the number of processes woken by complete_all(). That code already takes the lock and walks the list of processes to wake, ie. in order to wake them, so why not have it return the number of processes woken?

mpe
Doesn't complete_all just wake all processes? I'm not walking the process list at all, I'm just calling complete_all and letting it do its thing.
Alex
Yes complete_all() wakes all processes, and in doing so it must know how many "all" is, and it could return that to you. Someone might argue that's a hack, but I think it's a reasonable solution, and it's cleaner than walking the list again just to get the count.
mpe
+1  A: 

Hi Alex,

You may just want to change __wake_up_common so that it returns the number of tasks that have been woken up, and then modify complete_all to return that same number.

Have fun with your phone facing up and down.

By the way, an opaque struct will have a typedef struct whatever whatever_t, like atomic_t. Those are opaque.

Nico.

Nicolas Viennot