Linux kernel design patterns - part 2

Posted Jun 15, 2009 23:34 UTC (Mon) by neilbrown (subscriber, #359)
In reply to: Linux kernel design patterns - part 2 by johill
Parent article: Linux kernel design patterns - part 2

Yes, I guess that paragraph could be read as making a stronger statement than I can justify ... but if that sparks some discussion, maybe it isn't all bad.

My main goal was not to describe the best patterns, but to describe the value of patterns in general, and illustrate that with a few that I was aware of. The pattern that you describe is not one I have seen, and I suspect there are many more that I am not aware of. One of my hopes in writing the series was that it would encourage others to describe patterns they had seen and liked. You have at least partially realised this - thanks!

I imagine there would be a number of situations where that pattern would be very apt - possibly more apt than the pattern of simply exposing everything. What would be really useful (for any pattern) would be some analysis of strengths and weaknesses which could guide the choice of when it is a good one to use, and when it would best be avoided. Enumerating examples can help a lot there.

Thanks.

to post comments

Linux kernel design patterns - part 2

Posted Jun 16, 2009 10:13 UTC (Tue) by johill (subscriber, #25196) [Link]

Yes, I don't think you could possibly be aware of all patterns used. And it may well be possible that I brought this "partial exposure pattern" to the kernel myself, I've used it across the wireless code a lot but I don't know whether it is used elsewhere.

As for comparing, let me start with a very short comparison to the "expose everything" pattern:
Pros:

users forced to use APIs, less potential for abuse & "trickery"
internal details can be changed at will

Cons:

not possible to embed into anything, needs to be allocated by API function
cannot be allocated on stack

Other differences:

no "init" function/macro necessary, but "alloc" function contains "init".

For the cases where I've done it this way, the fact that it cannot be embedded or on the stack is not important because it serves more as the container itself rather than being a helper that can be embedded into something else. The one exception could be rfkill, but I made that completely opaque because it had been abused so much in the past.