In C# or C++ we have objects, instances of classes that are live in memory. The kernel also has objects, like interrupt objects. I wondered if these kernel objects can be thought of as we C# or C++ programmers objects?
+2
A:
The short answer is 'yes'. Objects are a state of mind. You can organize your work in objects in assembly language with a few macros, or in PL/I, or C, or C++. Some people might insist that it isn't an object without some sort of binding of dispatch to objects. Well, kernel/C object models use functions pointers to accomplish, somewhat more manually, what languages like C++, C#, or Java do.
What, after all, is an 'object'?
Answer 1: any lump of data that groups some related items. Any c struct. Some people would bridle and insist on ...
Answer 2: the combination of data and functions, such that code 'calls' the object, and the results depend on conditions set up by the creator of the object. So, in C++ or C# or Java, there is inheritance. Code calls SomeObject.someFunction(), and what happens depends on the inheritance graph, which is controlled by the object author, not by the caller.
In kernels, and in the pleistocene era when some of us learned to program, we accomplish(ed) the same thing, more or less, with simpler languages, using function pointers. That is to say, a slot in a structure that stores a reference to a function. The caller calls someobject.throwAnEgg, and what actually happens depends on what function pointer is sitting in `throwAnEgg'.
bmargulies
2010-01-01 22:40:15
sorry for sounding stupid, but can you explain what you mean with 'binding of dispatch to objects' and what you mean with 'functions pointers accomplish what languages like C++ etc do'?
Tony
2010-01-01 22:47:36
I edited, but you probably need to do some more reading.
bmargulies
2010-01-01 22:53:31
+1
A:
I think this should be tagged as subjective as the answers are going to vary and reflect the individual's personal view of things.
My take is this...
When you are talking about low-level stuff, sometimes, it is easier to bring in the perspective of OOP into it, to make it easier to communicate the concepts of what happens in the kernel level
...but...
I'd rather prefer to talk in terms of low-level nuts and bolts rather, because the complexity of the nuts and bolts can be easily solved by hammering it out, rather than talking and thinking in terms of objects because it is contriving and making a complex thing sound simple and setting yourself up for false thinking in terms of code economy.
For an example, from a kernel viewpoint, a TSS (Task State Segment) is a structure for holding the registers at the point before a task switch takes place (this is based on the processor being switched to 32bit and has paging enabled and so on). If you talk in terms of OOP aspect, i.e. a task selector object, that would not sound right because you're talking about a high level aspect when really, it is an actual nuts and bolts, take a look at the Intel 80386 programmer's manual, and there are references to the TSS, Chapter 13 - Protected-Mode Multitasking, Section 13.1 in the document 24143004.pdf available for download here
If you are talking high-level, from a high-level programming aspect, then it would be easier to define the OOP paradigm.
So, going back to your question, from a kernel aspect, you can if you wish, talk from a simplistic and concrete OOP terms, nonetheless, it would make you think in terms of having to put extra effort into coding in order to follow the OOP paradigm which may or could end up with convoluted code.
Hope this helps, Best regards, Tom.
tommieb75
2010-01-02 00:27:17
so what would you define these kernel objects as then? I like your viewpoint and I agree, if things are not the same, they should not be viewed as the same. I can see they are a form of data structure, that's for sure. But can you add to my definition?
Tony
2010-01-02 00:33:29
@Tony: How do you mean, add to your definition, I do not have enough rep to add another tag on to it. To answer your question, I would call them Kernel structures, rather than objects.. :)
tommieb75
2010-01-02 00:54:03
thing is, in the book I'm reading and lot of documentation, they are called kernel 'objects', that's why I asked this question originally, being a C#, C++ programmer.
Tony
2010-01-02 01:00:14
@Tony: Ahhh.... for the sake of absorbing information, a kernel object can be, task, memory, disk, to name but a few, that is purely from a theoretical viewpoint of the author of the book. In reality, I would call them, task structure, memory manager, disk manager. To represent those 'theoretical objects' does not necessarily define them as 'object' in the OOP paradigm. The author is just making it easy to explain in a nutshell, coding them and treating them as non-objects are a different beast altogether. Does this help?
tommieb75
2010-01-02 01:09:02
A:
If the book you are reading is about Linux you might be looking for kobject, which is simply an abstraction supporting Linux driver model. But in general any piece of data that is somehow associated with some behaviour like set of functions, macros, etc. might be called an object. This is much relaxed from more or less formal definition of object in OO languages like C# or C++.
Nikolai N Fetissov
2010-01-02 01:35:25