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
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
>
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
"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
"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
"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
"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
"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
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
12 matches
Mail list logo
