Re: why only C?

2011-04-06 Thread StephanT

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


Re: why only C?

2011-04-06 Thread mohit verma
thanks a lot guys
On Wed, Apr 6, 2011 at 11:07 PM, StephanT stman937-linew...@yahoo.comwrote:


 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*
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: why only C?

2011-04-04 Thread mohit verma
On Mon, Apr 4, 2011 at 1:19 AM, Bernd Petrovitsch be...@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 : be...@petrovitsch.priv.at
 LUGA : http://www.luga.at




-- 

*MOHIT VERMA*
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: why only C?

2011-04-04 Thread Bernd Petrovitsch
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 

Re: why only C?

2011-04-03 Thread Anuz Pratap Singh Tomar
On Sun, Apr 3, 2011 at 8:17 PM, mohit verma mohit89m...@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
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: why only C?

2011-04-03 Thread Daniel Baluta
On Sun, Apr 3, 2011 at 10:17 PM, mohit verma mohit89m...@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

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: why only C?

2011-04-03 Thread Chaitannya Mahatme




On Monday 04 April 2011 01:19 AM, Bernd Petrovitsch 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.
  

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

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 focus
is on application development. Java plays an important role in
isolating low level hardware issues. That's why you have Java as a
proffered choice for mobile apps and not C. 
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. 


  
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
  



-- 
Cheers !!!
Chaitannya

follow me on twitter http://twitter.com/chaitannya


I believe there's a hero in all of us 
who keeps us honest, gives us strength, makes us noble, and finally
allows us to die with pride,
even though sometimes we have to be steady, and give up the thing we
want the most... even our dreams.
- Spider Man 2




___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies