Re: linux-kernel-digest V1 #1132

From: Kimball Thurston (kimball@sgrail.com)
Date: Wed Jul 12 2000 - 23:56:18 EST


> From: Alexander Viro <viro@math.psu.edu>
> Date: Wed, 12 Jul 2000 23:46:04 -0400 (EDT)
> Subject: Re: Object Oriented Linux
>
> On Thu, 13 Jul 2000, Andrew Morton wrote:
>
> > inline void *operator new(size_t size)
> > {
> > return kmalloc(size);
> > }
>
> Yes? Care to compile that? FYI, kmalloc() has _two_ arguments. And no, I'm
> not being pedantic - choice of the second argument matters. Big way. C++
> has a notion of "allocation", but kernel has not. What it has is "atomic
> allocation", "dma-suitable allocation", etc. Choosing the right one is
> _not_ a task for compiler - it's AI-complete. Always forcing atomic is not
> an option, BTW - performance hit will be too serious.

#include <linux/mm.h>

typedef unsigned int size_t;

extern "C" void *kmalloc( size_t, int );
extern "C" void kfree( const void *pnt );

#define NEW new( SLAB_ATOMIC )

inline void *operator new( size_t size, int slab )
{
        return kmalloc( size, slab );
}
 
inline void *operator new[]( size_t size, int slab )
{
        return kmalloc( size, slab );
}
 
inline void operator delete( void *pnt )
{
        kfree( pnt );
}
 
inline void operator delete[]( void *pnt )
{
        kfree( pnt );
}
 
char *foo( int n )
{
        return NEW char[n];
}
 
char *bar( int n )
{
        return new( SLAB_DMA ) char[n];
}
 
void junk( void )
{
        char *a = foo( 10 );
        char *b = bar( 20 );

        delete [] a;
        delete [] b;
}

This will work. compile with g++ -c -fno-exceptions -O t.cc ...

Just wanted to say that it IS possible to declare new operators to use
kmalloc and pass in the arguments.... whether that make C++ a valid
choice for a kernel is a different issue - you have more abstract issues
to deal with than getting it to compile like inconsistent name mangling
semantics between different compilers (i.e. I compile my module with SGI
cc, you compile kernel module I depend on with gcc - different name
mangling, lots of unresolved symbols if there are C++ symbols to be
resolved), and the compiler having freedom to decide that what you wrote
isn't what you really want to do (declare an inline virtual function...
many compilers will let you, but it isn't going to be inline....).

Thanks to everyone for their work on linux...

later,

-- 
Kimball
mailto:kimball@sgrail.com
---------------
Efficiency is intelligent laziness.  - D. Dunham

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:16 EST