On Tue, Oct 24, 2000 at 09:38:13AM -0700, Stephen Satchell wrote:
> At 01:30 PM 10/22/00 +0200, you wrote:
> >Yup. And I want to try out my modules coded in Visual Cobol, APL,
> >and PL/I. Oh, and I want to rewrite ext2fs to use Befunge.
>
> Would that be PL/I (F) or PL/I (H}? You have
Timur Tabi <[EMAIL PROTECTED]> writes:
|> ** Reply to message from Stephen Satchell <[EMAIL PROTECTED]> on
|> Tue, 24 Oct 2000 09:54:46 -0700
|>
|>
|> > Linus has the final say, of course, but to suggest that any changes that
|> > remove name collisions between C and C++ be rejected out of
** Reply to message from Stephen Satchell <[EMAIL PROTECTED]> on
Tue, 24 Oct 2000 09:54:46 -0700
> Linus has the final say, of course, but to suggest that any changes that
> remove name collisions between C and C++ be rejected out of hand has the
> potential for shooting ourselves in the
At 04:37 PM 10/23/00 +0200, Marko Kreen wrote:
>* This will _not_ be accepted into standard codebase. Don't you
>understand? Making headers C++ compatible is the first tiny
>step for doing modules in C++. Yes, from driver/module
>programmers perspective "they almost look same, and
At 01:30 PM 10/22/00 +0200, you wrote:
>Yup. And I want to try out my modules coded in Visual Cobol, APL,
>and PL/I. Oh, and I want to rewrite ext2fs to use Befunge.
Would that be PL/I (F) or PL/I (H}? You have different footprint problems
with each of these levels. You will also need to
At 01:30 PM 10/22/00 +0200, you wrote:
Yup. And I want to try out my modules coded in Visual Cobol, APL,
and PL/I. Oh, and I want to rewrite ext2fs to use Befunge.
Would that be PL/I (F) or PL/I (H}? You have different footprint problems
with each of these levels. You will also need to write
At 04:37 PM 10/23/00 +0200, Marko Kreen wrote:
* This will _not_ be accepted into standard codebase. Don't you
understand? Making headers C++ compatible is the first tiny
step for doing modules in C++. Yes, from driver/module
programmers perspective "they almost look same, and I
** Reply to message from Stephen Satchell [EMAIL PROTECTED] on
Tue, 24 Oct 2000 09:54:46 -0700
Linus has the final say, of course, but to suggest that any changes that
remove name collisions between C and C++ be rejected out of hand has the
potential for shooting ourselves in the foot.
Timur Tabi [EMAIL PROTECTED] writes:
| ** Reply to message from Stephen Satchell [EMAIL PROTECTED] on
| Tue, 24 Oct 2000 09:54:46 -0700
|
|
| Linus has the final say, of course, but to suggest that any changes that
| remove name collisions between C and C++ be rejected out of hand has the
On Tue, Oct 24, 2000 at 09:38:13AM -0700, Stephen Satchell wrote:
At 01:30 PM 10/22/00 +0200, you wrote:
Yup. And I want to try out my modules coded in Visual Cobol, APL,
and PL/I. Oh, and I want to rewrite ext2fs to use Befunge.
Would that be PL/I (F) or PL/I (H}? You have different
OK I've decided to give this a shot, IF there is sufficient interest out
there for C++ safe headers. So all you coders out there who have tried and
failed or who wish to program kernel modules in C++ join in and help out by
listing the errors you have encountered with the current header
"Linux Kernel Developer" <[EMAIL PROTECTED]> said:
> Wasn't the original complaint that the kernel headers use C++ keyword
> and thus prevent the writing of, at least some, modules in C++. I have
> written C++ code before that was as least as fast as comparable C code and
> more efficient in
Wasn't the original complaint that the kernel headers use C++ keyword
and thus prevent the writing of, at least some, modules in C++. I have
written C++ code before that was as least as fast as comparable C code and
more efficient in some ways. Whether this could be or not be reproduced in
Marty Fouts wrote:
>
> I prefer Peter Salus' wording, myself: The difference between theory and
> practice is always larger in practice than in theory.
I didn't know this brilliant quote.
About the bloat:
I think C++ would give you some bloat. But that bloat is
mainly in the footprint (you
Wasn't the original complaint that the kernel headers use C++ keyword
and thus prevent the writing of, at least some, modules in C++. I have
written C++ code before that was as least as fast as comparable C code and
more efficient in some ways. Whether this could be or not be reproduced in
"Linux Kernel Developer" [EMAIL PROTECTED] said:
Wasn't the original complaint that the kernel headers use C++ keyword
and thus prevent the writing of, at least some, modules in C++. I have
written C++ code before that was as least as fast as comparable C code and
more efficient in some
I prefer Peter Salus' wording, myself: The difference between theory and
practice is always larger in practice than in theory.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Eray Ozkural <[EMAIL PROTECTED]> said:
> Rik van Riel wrote:
> > If C++ really is that good for kernel modules, I'd like to
> > see some code that proves it can be done without too much
> > of a performance hit (or without a performance hit at all?).
> it can be done in theory :)
"Theory and
On Sat, 21 Oct 2000, Eray Ozkural wrote:
> Rik van Riel wrote:
> > If C++ really is that good for kernel modules, I'd like to
> > see some code that proves it can be done without too much
> > of a performance hit (or without a performance hit at all?).
>
> it can be done in theory :)
I guess
Rik van Riel wrote:
> If C++ really is that good for kernel modules, I'd like to
> see some code that proves it can be done without too much
> of a performance hit (or without a performance hit at all?).
>
it can be done in theory :)
> Sending 500 rants to the kernel list isn't even close to
>
On Tue, 17 Oct 2000, Eray Ozkural wrote:
> Let it remain C as you like it. I'm just telling that
>
> * you can't prevent people from writing C++ linux modules as they like
> * you are making unfair criticism of C++ language
Let me add one more point:
* you can't get the C++ advocates to
On Tue, 17 Oct 2000, Eray Ozkural wrote:
Let it remain C as you like it. I'm just telling that
* you can't prevent people from writing C++ linux modules as they like
* you are making unfair criticism of C++ language
Let me add one more point:
* you can't get the C++ advocates to write
Rik van Riel wrote:
If C++ really is that good for kernel modules, I'd like to
see some code that proves it can be done without too much
of a performance hit (or without a performance hit at all?).
it can be done in theory :)
Sending 500 rants to the kernel list isn't even close to
being
On Sat, 21 Oct 2000, Eray Ozkural wrote:
Rik van Riel wrote:
If C++ really is that good for kernel modules, I'd like to
see some code that proves it can be done without too much
of a performance hit (or without a performance hit at all?).
it can be done in theory :)
I guess I'll have
Eray Ozkural [EMAIL PROTECTED] said:
Rik van Riel wrote:
If C++ really is that good for kernel modules, I'd like to
see some code that proves it can be done without too much
of a performance hit (or without a performance hit at all?).
it can be done in theory :)
"Theory and practice are
I prefer Peter Salus' wording, myself: The difference between theory and
practice is always larger in practice than in theory.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[Peter Samuelson]
> > Is this similar to the gcc 'const' attribute?
> >
> > int foo (int, char *) __attribute__((__const__));
> >
> > This is valid in GNU C (not just C++). Read the info page for
> > details.
[Eray Ozkural]
> Probably, I haven't used it in my C code though. I've found an
"Jeff V. Merkey" wrote:
>
> Tell you what. You should go look into the Chorus or TMOK projects that
> are based on C++ and pester them.
Fine. I don't want to waste my time with somebody else's crap though!
> Next you'll be telling me that IDL
> and Corba stubs in every layer of the OS are in
On Tue, Oct 17, 2000 at 07:11:36AM +, Peter Samuelson wrote:
> > I can't say whether putting libstdc++ in a kernel module is a bad thing
> > before I see one. This is a skel. code:
>
> > -rw-r--r--1 root root 271528 Oct 10 09:54
>/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
> >
[Eray Ozkural]
> I can't say whether putting libstdc++ in a kernel module is a bad thing
> before I see one. This is a skel. code:
> -rw-r--r--1 root root 271528 Oct 10 09:54
>/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
> orion:opt$ ls -al /usr/lib/libstdc++-3-libc6.2-2-2.10.0.a
>
[Eray Ozkural]
I can't say whether putting libstdc++ in a kernel module is a bad thing
before I see one. This is a skel. code:
-rw-r--r--1 root root 271528 Oct 10 09:54
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
orion:opt$ ls -al /usr/lib/libstdc++-3-libc6.2-2-2.10.0.a
On Tue, Oct 17, 2000 at 07:11:36AM +, Peter Samuelson wrote:
I can't say whether putting libstdc++ in a kernel module is a bad thing
before I see one. This is a skel. code:
-rw-r--r--1 root root 271528 Oct 10 09:54
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
orion:opt$
Eray Ozkural <[EMAIL PROTECTED]> wrote:
> I've read a summary of a discussion about C++ module writing on
> this list, and I'd like to make some comments on it. [I'm not
> subscribed to this list, please retain a Cc: to my address]
I've had the (dubious) opportunity to write a C++
kernel
** Reply to message from Eray Ozkural <[EMAIL PROTECTED]> on Mon, 16 Oct
2000 07:55:30 +0300
> I don't want to repeat myself, but C++ doesn't force you to use
> any bad programming practice that will result in slow code:
> * exceptions everywhere
> * polymorphism everywhere
> * dynamic
** Reply to message from "Jeff V. Merkey" <[EMAIL PROTECTED]> on Sun, 15
Oct 2000 18:06:05 -0600
> The [new] and constructor/destructor operations create hidden memory
> allocations in C++ that can blow performance in kernel "fast paths".
I don't consider the memory allocation that [new] and
On Mon, Oct 16, 2000 at 02:49:47PM +0200, Igmar Palsenberg wrote:
> On Mon, 16 Oct 2000, Jeff V. Merkey wrote:
>
> >
> > Not meant to offend, but it's obvious you are not grasping hardware
> > optimization issues relative to kernel development and performance. I
> > would recommend getting
On Mon, 16 Oct 2000, Jeff V. Merkey wrote:
>
> Not meant to offend, but it's obvious you are not grasping hardware
> optimization issues relative to kernel development and performance. I
> would recommend getting your hands on a bus analyzer, and testing out
> some of your theories, and
Tell you what. You should go look into the Chorus or TMOK projects that
are based on C++ and pester them. Next you'll be telling me that IDL
and Corba stubs in every layer of the OS are in order and won't hurt
performance. I did this OOM mental mastrubation excercise with the USL
folks 7
"Jeff V. Merkey" wrote:
>
> Not meant to offend, but it's obvious you are not grasping hardware
> optimization issues relative to kernel development and performance. I
> would recommend getting your hands on a bus analyzer, and testing out
> some of your theories, and explore for yourself
Actually, I spent four months at Novell profiling Chorus, MACH and TMOK
(Trusted Modular Object Kernel -- a very nice piece of work) with EMON
and an AArium profiling bus footprints -- the result. C++ kernels are
slightly slower, and hit the wall on I/O performance due to excessive
memory
Firs of all, as someone said, is there any other list where we can discuss this
?
It is ver off-topic here...
I messed in the discussion because I'm tired of seein people say that they don't
use
C++ because their big overheads, being slow, messed, out of programmer's control
for
low level tasks
Monday, October 16, 2000 1:05 AM
> To: Marty Fouts
> Cc: 'Jeff V. Merkey'; [EMAIL PROTECTED]
> Subject: RE: [Criticism] On the discussion about C++ modules
>
> On Mon, 16 Oct 2000, Marty Fouts wrote:
>
> > Which part of "what you wrote doesn't make sense, (for
point out bogosities
when they come up?
-Original Message-
From: Tigran Aivazian [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 16, 2000 1:05 AM
To: Marty Fouts
Cc: 'Jeff V. Merkey'; [EMAIL PROTECTED]
Subject: RE: [Criticism] On the discussion about C++ modules
On Mon, 16 Oct 2000, Marty
On Mon, 16 Oct 2000, Marty Fouts wrote:
> Which part of "what you wrote doesn't make sense, (for the following
> reasons,) please explain it" are you having trouble responding to in public?
the pragmatic and subjective part. Jeff wrote some cool nwfs code for
Linux which is publically available
day, October 15, 2000 11:20 PM
> To: [EMAIL PROTECTED]
> Cc: J . A . Magallon; [EMAIL PROTECTED]
> Subject: Re: [Criticism] On the discussion about C++ modules
>
> Not meant to offend, but it's obvious you are not grasping hardware
> optimization issues relative to kernel development and
er 15, 2000 11:20 PM
> To: [EMAIL PROTECTED]
> Cc: J . A . Magallon; [EMAIL PROTECTED]
> Subject: Re: [Criticism] On the discussion about C++ modules
>
> Not meant to offend, but it's obvious you are not grasping hardware
> optimization issues relative to kernel development and performan
Message-
From: Jeff V. Merkey [mailto:[EMAIL PROTECTED]]
Sent: Sunday, October 15, 2000 11:20 PM
To: [EMAIL PROTECTED]
Cc: J . A . Magallon; [EMAIL PROTECTED]
Subject: Re: [Criticism] On the discussion about C++ modules
Not meant to offend, but it's obvious you are not grasping hardware
Hi,
I hope IF C++ kernel modules written I could find the same module written in
C too, because I would refuse using C++ in kernel for various reasons.
I'm Hungarian guy and I can speak English (yeah, only a bit ;-).
Note that I can't make Hungarian the default language for a software
made for
Not meant to offend, but it's obvious you are not grasping hardware
optimization issues relative to kernel development and performance. I
would recommend getting your hands on a bus analyzer, and testing out
some of your theories, and explore for yourself relative to these issues
with some hard
Not meant to offend, but it's obvious you are not grasping hardware
optimization issues relative to kernel development and performance. I
would recommend getting your hands on a bus analyzer, and testing out
some of your theories, and explore for yourself relative to these issues
with some hard
Message-
From: Jeff V. Merkey [mailto:[EMAIL PROTECTED]]
Sent: Sunday, October 15, 2000 11:20 PM
To: [EMAIL PROTECTED]
Cc: J . A . Magallon; [EMAIL PROTECTED]
Subject: Re: [Criticism] On the discussion about C++ modules
Not meant to offend, but it's obvious you are not grasping hardware
: [Criticism] On the discussion about C++ modules
Not meant to offend, but it's obvious you are not grasping hardware
optimization issues relative to kernel development and performance. I
would recommend getting your hands on a bus analyzer, and testing out
some of your theories, and explore
point out bogosities
when they come up?
-Original Message-
From: Tigran Aivazian [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 16, 2000 1:05 AM
To: Marty Fouts
Cc: 'Jeff V. Merkey'; [EMAIL PROTECTED]
Subject: RE: [Criticism] On the discussion about C++ modules
On Mon, 16 Oct 2000, Marty
Firs of all, as someone said, is there any other list where we can discuss this
?
It is ver off-topic here...
I messed in the discussion because I'm tired of seein people say that they don't
use
C++ because their big overheads, being slow, messed, out of programmer's control
for
low level tasks
Actually, I spent four months at Novell profiling Chorus, MACH and TMOK
(Trusted Modular Object Kernel -- a very nice piece of work) with EMON
and an AArium profiling bus footprints -- the result. C++ kernels are
slightly slower, and hit the wall on I/O performance due to excessive
memory
** Reply to message from "Jeff V. Merkey" [EMAIL PROTECTED] on Sun, 15
Oct 2000 18:06:05 -0600
The [new] and constructor/destructor operations create hidden memory
allocations in C++ that can blow performance in kernel "fast paths".
I don't consider the memory allocation that [new] and
Eray Ozkural [EMAIL PROTECTED] wrote:
I've read a summary of a discussion about C++ module writing on
this list, and I'd like to make some comments on it. [I'm not
subscribed to this list, please retain a Cc: to my address]
I've had the (dubious) opportunity to write a C++
kernel
"Jeff V. Merkey" wrote:
>
> Eray Ozkural wrote:
> >
> > I don't how you would do such a thing in C++. Allocators and the
> > stuff I talked about make it more efficient and safer to manage
> > memory. They don't throw memory calls all over the place. :P
>
> More routines touching more memory on
"J . A . Magallon" <[EMAIL PROTECTED]> said:
[...]
> But there are some features of C++ that would be of great value for kernel
> development (in general for imperative programming), for example:
> - args : dont break your untouchable data, and get rid of
> pointer mess
It isn't _that_
Eray Ozkural wrote:
>
> "Jeff V. Merkey" wrote:
> > There are some elements that are attractive, but overall, why would a
> > device thread want to allocate memory from an interrupt
>
> I don't how you would do such a thing in C++. Allocators and the
> stuff I talked about make it more
"Jeff V. Merkey" wrote:
> There are some elements that are attractive, but overall, why would a
> device thread want to allocate memory from an interrupt
I don't how you would do such a thing in C++. Allocators and the
stuff I talked about make it more efficient and safer to manage
memory. They
C++ in kernel development should be discouraged in general. Structured
Exception handling would be a nice C++ implementation in Linux, and the
way the FS is using the name : function construct for the VFS function
tables is very nice as well since we don't have to align the strucures.
There
"J . A . Magallon" wrote:
> I agree that C++ for kernel is not a good idea, libstdc++ should be in the
> kernel,
> code would be bigger, there's a complicated runtime under C++ doing things
> by itself (copy constructors-operators and so on), inheritance adds some
> little calling overhead.
>
"Jeff V. Merkey" wrote:
>
> The [new] and constructor/destructor operations create hidden memory
> allocations in C++ that can blow performance in kernel "fast paths".
That is designed to decrease the number of syscalls, not to increase
them. Besides, in a successful C++ design memory
On Mon, 16 Oct 2000 02:06:05 Jeff V. Merkey wrote:
>
>
> The [new] and constructor/destructor operations create hidden memory
> allocations in C++ that can blow performance in kernel "fast paths".
> Writing kernel code in C++ is never a good idea because of this problem,
I agree that C++ for
The [new] and constructor/destructor operations create hidden memory
allocations in C++ that can blow performance in kernel "fast paths".
Writing kernel code in C++ is never a good idea because of this problem,
and the fact that with function overloading, it's possible for someone
to write
Hi,
I've read a summary of a discussion about C++ module writing on
this list, and I'd like to make some comments on it. [I'm not
subscribed to this list, please retain a Cc: to my address]
To rephrase, Stepan Kasal had started writing a C++ kernel module
and while including kernel headers he
Hi,
I've read a summary of a discussion about C++ module writing on
this list, and I'd like to make some comments on it. [I'm not
subscribed to this list, please retain a Cc: to my address]
To rephrase, Stepan Kasal had started writing a C++ kernel module
and while including kernel headers he
"J . A . Magallon" wrote:
I agree that C++ for kernel is not a good idea, libstdc++ should be in the
kernel,
code would be bigger, there's a complicated runtime under C++ doing things
by itself (copy constructors-operators and so on), inheritance adds some
little calling overhead.
You can
C++ in kernel development should be discouraged in general. Structured
Exception handling would be a nice C++ implementation in Linux, and the
way the FS is using the name : function construct for the VFS function
tables is very nice as well since we don't have to align the strucures.
There
70 matches
Mail list logo
