Hi list, I have a very basic question. As far as i can decipher , we impose Object oriented paradigm in kernel space using C : like using gates to allow only one way entry and binding functions to structures in a OOP fashion and trying to make them private to that structure only , encapsulation of one struct into another structure (and lots of features ) and itself lots of kernel subsystem supports like driver interface and blah blah behaving like **objects** ....... why dont we use some fully OOPs supportive language like JAVA or partial supportive language like C++ to construct Linux Kernel???? I don't think that performance is the main reason behind all this . Is it?? Thanks a lot in advance. -- ........................ *MOHIT VERMA*
On Sun, Apr 3, 2011 at 8:17 PM, mohit verma <mohit89mlnc@gmail.com> wrote:
Hi list,
I have a very basic question.
As far as i can decipher , we impose Object oriented paradigm in kernel space using C : like using gates to allow only one way entry and binding functions to structures in a OOP fashion and trying to make them private to that structure only , encapsulation of one struct into another structure (and lots of features ) and itself lots of kernel subsystem supports like driver interface and blah blah behaving like **objects** .......
why dont we use some fully OOPs supportive language like JAVA or partial supportive language like C++ to construct Linux Kernel????
I don't think that performance is the main reason behind all this . Is it??
Thanks a lot in advance.
Read more or even google it. Besides its Design decision by Linus Torvalds Here is the historic mail explaining what he said *From: Linus Torvalds* [email blocked] Subject: Re: Compiling C++ kernel module + Makefile Date: Mon, 19 Jan 2004 22:46:23 -0800 (PST) On Tue, 20 Jan 2004, Robin Rosenberg wrote:
This is the "We've always used COBOL^H^H^H^H" argument.
In fact, in Linux we did try C++ once already, back in 1992. It sucks. Trust me - writing kernel code in C++ is a BLOODY STUPID IDEA. The fact is, C++ compilers are not trustworthy. They were even worse in 1992, but some fundamental facts haven't changed: - the whole C++ exception handling thing is fundamentally broken. It's _especially_ broken for kernels. - any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel. - you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++. In general, I'd say that anybody who designs his kernel modules for C++ is either (a) looking for problems (b) a C++ bigot that can't see what he is writing is really just C anyway (c) was given an assignment in CS class to do so. Feel free to make up (d). Linus
On Sun, Apr 3, 2011 at 10:17 PM, mohit verma <mohit89mlnc@gmail.com> wrote:
Hi list, I have a very basic question.
How much time have you tried documenting on this topic [1]? thanks, Daniel. [1] http://answers.google.com/answers/threadview/id/718661.html
Hi! On Mon, 2011-04-04 at 00:47 +0530, mohit verma wrote: [....]
As far as i can decipher , we impose Object oriented paradigm in kernel space using C : like using gates to allow only one way entry and binding functions to structures in a OOP fashion and trying to make them private to that structure only , encapsulation of one struct into another structure (and lots of features ) and itself lots of kernel subsystem supports like driver interface and blah blah behaving like **objects** .......
OOP is a design issue independent of the used programming language. So you actually *can* do OOP with C (or assembler or ....) and I have seen C++ programs which do not employ the ideas behind OOP.
why dont we use some fully OOPs supportive language like JAVA or partial supportive language like C++ to construct Linux Kernel????
What does it buy and what does it cost? For - or more against - Java: You really do not want an OS to use an interpreted "language". That kills performance. And the more interesting challenge is to implement hardware IRQ handlers in Java. C++ has lots of features which make it awkward to use. For starters, think about the fact that Java does not have multiple inheritance.
I don't think that performance is the main reason behind all this . Is it??
Did you google for it and read the links etc.? You will find much more on this question. Bernd -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at LUGA : http://www.luga.at
Hi! On Mon, 2011-04-04 at 06:00 +0530, Chaitannya Mahatme wrote:
On Monday 04 April 2011 01:19 AM, Bernd Petrovitsch wrote: [...]
On Mon, 2011-04-04 at 00:47 +0530, mohit verma wrote: [....]
As far as i can decipher , we impose Object oriented paradigm in kernel space using C : like using gates to allow only one way entry and binding functions to structures in a OOP fashion and trying to make them private to that structure only , encapsulation of one struct into another structure (and lots of features ) and itself lots of kernel subsystem supports like driver interface and blah blah behaving like **objects** .......
OOP is a design issue independent of the used programming language. So you actually *can* do OOP with C (or assembler or ....) and I have seen C++ programs which do not employ the ideas behind OOP.
why dont we use some fully OOPs supportive language like JAVA or partial supportive language like C++ to construct Linux Kernel????
What does it buy and what does it cost?
For - or more against - Java: You really do not want an OS to use an interpreted "language". That kills performance. And the more interesting challenge is to implement hardware IRQ handlers in Java.
JVM has been optimised to such a level that it beats C++ in performance. Only thing faster than that is C and assembly language. A
In which benchmarks? I forgot to differentiate: Above I assumed the clichee Java-app witch is run via a (usually not so small) JVM[0]. The alternative is to compile the Java bytecode (or Java source directly) into native machine code - and that as such can be probably as fast as C (provided one avoids the kmalloc()/kfree() trashing (or whatever it is called there) for each object and control the inherent features like garbage collection). In both cases, I doubt that one want to live in a kernel with - garbage collection and - apart from the simple arithmetic types - only "objects". It is as if every struct in the kernel is allocated via kmalloc(). - You have various parts which are inherently CPU-dependent - starting with IRQ handlers and memory management where you really have to live with the hardware. So you will end up with a lower part written in C (or whatever) and the higher layers in something completely different. For a "use Java for an OS" approach, it is probably way better/easier to take an existing microkernel and build the various drivers/servers/... in Java.
few chips process Java byte code at hardware level as well. Read this http://en.wikipedia.org/wiki/Jazelle ... So this can't be a valid argument.
Well, you want the Linux kernel (or any other real kernel) to run on virtually any hardware so a "few chips" don't really help as a point for Java bytecode. Perhaps/probably it's good to use it on these "few chips" but that doesn't help the server and desktop world with Intel and AMD CPUS and the embedded worlds with ARM, MIPS, PowerPC, etc.
The key thing over here is purpose. OOP based languages are essentially meant to abstract the developers from the hassles of low level operations (Assuming a programmer well versed with OOP) , so the
In my experience you have in an application many more than 2 levels - some more explicit like libraries, some less explicit within the application. And you really want to design it so that the higher levels abstract more than the next lower level. But with every abstraction level, you loose some influence/control and the key question is if you can live with it. For a pure userspace application, it is (usually, in most cases) not an issue and and an issue is to get correct working software in (quite) short time (so e.g. some garbage collector seems useful). Well, in realtime applications, you probably do not want some general purpose garbage collector to chime in for 2 seconds at the wrong time. RAM is in desktop and server applications not really an issue as it's cheap. In the embedded world, you may have only 8 or 16MB RAM in the system (and no, I consider smart phones with 128MB RAM and a touch screen in no way "embedded", there are just small PCs). I worked once for a company building an embedded system with 4MB FlashRAM for the firmware image and 16MB RAM (and 50MHz PowerPC-based 32bit CPU). And that's the class of problems one also has in a kernel.
focus is on application development. Java plays an important role in isolating low level hardware issues. That's why you have Java as a
Java claims to be portable everywhere. So they refuse to deliver features which are not available everywhere (e.g. AF_UNIX sockets). That boils down to the least common denominator of available features. But there are lots of situations where "total portability" is not important.
proffered choice for mobile apps and not C.
IMHO it was just hyped at that time and the programmers there nowadays are trained/used/know how to work around the problems with it. Let's see on the first project in that direction if they really know what protocols, encodings, data formats, etc. .... their apps really use on the wire (or more on TCP/IP) if the server side is on a small/real embedded system where some Java implementation is plain simply not possible. Or at least if they can find the documentation for that;-)
If you are developing kernel, you are programming bare metal. You have to do low level operations like loading the program into the memory, defining it's data segment, code segment, etc. Hence C is the obvious choice since it's the closest to the hardware (meaning simple to deal low level operations) and well structured than assembly language.
FullACK. There is the saying the "C is just a portable assembler";-) Bernd [0]: Yes, there is "embedded Java". I never looked into it. -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at LUGA : http://www.luga.at
On Mon, Apr 4, 2011 at 1:19 AM, Bernd Petrovitsch <bernd@petrovitsch.priv.at
wrote:
Hi!
On Mon, 2011-04-04 at 00:47 +0530, mohit verma wrote: [....]
As far as i can decipher , we impose Object oriented paradigm in kernel space using C : like using gates to allow only one way entry and binding functions to structures in a OOP fashion and trying to make them private to that structure only , encapsulation of one struct into another structure (and lots of features ) and itself lots of kernel subsystem supports like driver interface and blah blah behaving like **objects** .......
OOP is a design issue independent of the used programming language. So you actually *can* do OOP with C (or assembler or ....) and I have seen C++ programs which do not employ the ideas behind OOP.
why dont we use some fully OOPs supportive language like JAVA or partial supportive language like C++ to construct Linux Kernel????
What does it buy and what does it cost?
For - or more against - Java: You really do not want an OS to use an interpreted "language". That kills performance. And the more interesting challenge is to implement hardware IRQ handlers in Java.
C++ has lots of features which make it awkward to use. For starters, think about the fact that Java does not have multiple inheritance.
I don't think that performance is the main reason behind all this . Is it??
Did you google for it and read the links etc.? You will find much more on this question.
the above two responses can easily describe : **why** did i post this mail ? And literally , i had googled it before posting to this list. C++ is not that much stupid now a days if we compare it to old (1992) days...... but still C??
Bernd -- Bernd Petrovitsch Email : bernd@petrovitsch.priv.at LUGA : http://www.luga.at
-- ........................ *MOHIT VERMA*
why dont we use some fully OOPs supportive language like JAVA or partial supportive language like C++ to construct Linux Kernel????
Hi Mohit, This is an old debate, which by the way extends to the whole embedded realm, not only to Linux. The best way to get an acceptable answer and understanding to your question is to do some work by yourself. Start by writing a very basic scheduler for some embedded platform. You may use even your PC for this. Consider two tasks, one writing "A" and the other "B" to the console. Read "Just for Fun: The Story of an Accidental Revolutionary" by Linus Torvalds and David Diamond. Linus explains in grand detail how this can be done on your PC. Once you got it in "C" start again and write it in "C++" and why not in "Java". And when you done with all this exercise, please come back here and publish your code and conclusions. Everybody and especially you will have to learn from this experiment. At my knowledge it has not yet been done by anyone. You may bind and lead a team of volunteers willing to participate to this experiment. It will go faster. I really think this is the way to get a clearer idea about the best tools to write embedded software. Best luck in this endeavor, Stephan.
thanks a lot guys.... On Wed, Apr 6, 2011 at 11:07 PM, StephanT <stman937-linewbie@yahoo.com>wrote:
why dont we use some fully OOPs supportive language like JAVA or partial supportive language like C++ to construct Linux Kernel????
Hi Mohit,
This is an old debate, which by the way extends to the whole embedded realm, not only to Linux. The best way to get an acceptable answer and understanding to your question is to do some work by yourself.
Start by writing a very basic scheduler for some embedded platform. You may use even your PC for this. Consider two tasks, one writing "A" and the other "B" to the console. Read "Just for Fun: The Story of an Accidental Revolutionary" by Linus Torvalds and David Diamond. Linus explains in grand detail how this can be done on your PC.
Once you got it in "C" start again and write it in "C++" and why not in "Java". And when you done with all this exercise, please come back here and publish your code and conclusions. Everybody and especially you will have to learn from this experiment. At my knowledge it has not yet been done by anyone.
You may bind and lead a team of volunteers willing to participate to this experiment. It will go faster. I really think this is the way to get a clearer idea about the best tools to write embedded software.
Best luck in this endeavor, Stephan.
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- ........................ *MOHIT VERMA*
participants (6)
-
Anuz Pratap Singh Tomar -
Bernd Petrovitsch -
Chaitannya Mahatme -
Daniel Baluta -
mohit verma -
StephanT