User: Password:
|
|
Subscribe / Log in / New account

Object-oriented design patterns in the kernel, part 2

Object-oriented design patterns in the kernel, part 2

Posted Jun 9, 2011 23:32 UTC (Thu) by daglwn (guest, #65432)
In reply to: Object-oriented design patterns in the kernel, part 2 by janneke
Parent article: Object-oriented design patterns in the kernel, part 2

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."


(Log in to post comments)

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". :)


Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds