why only C?

why only C?

[mohit verma]

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*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110404/269fd7c5/attachment.html 

why only C?

[Anuz Pratap Singh Tomar]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110403/43283431/attachment.html 

why only C?

[Daniel Baluta]

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

why only C?

[Bernd Petrovitsch]

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 at petrovitsch.priv.at
                     LUGA : http://www.luga.at

why only C?

[Chaitannya Mahatme]

An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110404/6cd63d40/attachment.html 

why only C?

[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 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 at petrovitsch.priv.at
                     LUGA : http://www.luga.at

why only C?

[mohit verma]

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 at petrovitsch.priv.at
>                     LUGA : http://www.luga.at
>
>


-- 
........................
*MOHIT VERMA*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110404/ea18d06e/attachment-0002.html 

why only C?

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

why only C?

[mohit verma]

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 at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>



-- 
........................
*MOHIT VERMA*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110407/d8b94fcf/attachment.html