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
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 han
** 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.
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 write
On Mon, Oct 23, 2000 at 08:47:53AM -0400, Linux Kernel Developer wrote:
> Please comment on the pluses and minuses of each planned task and on
> other things that you may see that should be done. Please no flames unless
> they contain useful information. Also I plan to implement the first pa
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 setup
"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
On Sun, Oct 22, 2000 at 06:42:19AM -0400, Linux Kernel Developer wrote:
> 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 m
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
k
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 have
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 pra
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'l
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 wr
[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 o
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
> > ori
[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 <[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 typ
** 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 co
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 your
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 explore
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 years
"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 relati
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 read/w
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
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 Fouts wrote:
>
> > Which part of "what you wrote doesn't mak
still 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
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
o:[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
> optimization i
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
> optimization issues relative to kernel
ems.)
-Original 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
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 no
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
"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_ bad.
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 efficie
"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 d
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 ar
"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.
>
Yo
"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 allocation
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 code
46 matches
Mail list logo