| |||||||||||||
Object-oriented design patterns in the kernel, part 2Object-oriented design patterns in the kernel, part 2Posted Jun 9, 2011 8:35 UTC (Thu) by janneke (subscriber, #15012)Parent article: Object-oriented design patterns in the kernel, part 2
Thanks for your insightful article. Pleasantly surprised as I was by the five Exercises you provide at the end, I had been anticipating a question (if not a possible answer itself in part 3) like 5. Construct a miminal set of macros that implement the "object-oriented" boilerplating which has an object model that would meet all the needs of the Linux kernel as identified in these two articles. with your question #5 as an optional bonus [extra points] What am I missing?
(Log in to post comments)
Object-oriented design patterns in the kernel, part 2 Posted Jun 9, 2011 23:32 UTC (Thu) by daglwn (subscriber, #65432) [Link]
I think you're missing the definition of "needed." The articles did a good job of enumerating various object models in use as well as critiquing them. Just because the kernel does things the way it does today does not mean it is the best way or even a close-to-best way.
Any object model can be implemented in any sufficiently capable language. The key differences are in what the languages support "natively."
Object-oriented design patterns in the kernel, part 2 Posted Jun 13, 2011 3:24 UTC (Mon) by daniel (subscriber, #3181) [Link]
The answer to Niel's leading question is clearly "C++", which invites the additional exercise "how practical would that be?".
My answer: I'm not sure. The i_op pointer would become an opaque method table pointer, however it is clearly impractical to rewrite every filesystem in C++, so C code would require require a variant definition of struct inode with an explicit definition of the opaque pointer, and the opaque vtable it references would need an explicit definition available to C code. These structures are pretty simple, it might be possible to emulate them in C.
I wrote a little program to test this theory. I defined a simple class with an integer field and a virtual function to increment that field. I know the vtable pointer is stored in the first word of a virtual object and by inspection I found that the first word of the vtable points at my member function. And I know that c++ passes the address of an object as a hidden parameter to any class member function. I stepped through a normal call to my virtual method to verify nothing mysterious is going on. Then I added some casts to retrieve the vtable pointer from an object, read the member address out of the vtable, and call that address as a function with one parameter, the object address. Aha, it works.
Whether this is a good idea is another question. This behavior is compiler dependent, but on the other hand there aren't a lot of compilers in the running when it comes to Linux kernel. It could probably be made to work. Not that I would seriously suggest rewriting the VFS in C++. Perhaps a device driver.
Object-oriented design patterns in the kernel, part 2 Posted Jun 29, 2011 3:57 UTC (Wed) by xoddam (subscriber, #2322) [Link]
Now that's what I'd call "unwarranted chumminess with the implementation". :)
|
|||||||||||||