On Tue, 25 Apr 2006 11:22:32 +0200, Xavier Bestel <[email protected]> wrote: > > Yes, "if". With straight C, it's immediatly obvious the kmalloc() is the > only function with side-effects and special requirements - an > experienced hacker won't even look it up. With C++ those may be hidden > behind each object or object member, that's the philosophy of the > language. > The problem is that in kernel mode you must know precisely when and how > you allocate memory. > Don't mix allocation with initialization. Well, lets see: struct xxx { struct yyy* y; int z; } xxx_init(struct xxx* x) { z = 0; y = kmalloc(GPF_KERNEL,sizeof(struct yyy)); yyy_init(y); } Now, if on other source file you read: ... struct xxx* x; x = kmallloc(GPF_KERNEL,sizeof(struct xxx)); xxx_init(x); .. struct xxx x2; xxx_init(&x2); How do you know what xxx_init() does without looking at it ? Cay you have just the allocation without init ? What happens if you forget it ? What happens if you cut'n'paste from other driver and let something like struct xxx* x; x = kmallloc(GPF_KERNEL,sizeof(struct qqqqq)); xxx_init(x); The only difference it that x = new(GPF_KERNEL) XXX; always does what it has to do correctly. What does XXX() constructor ? You have to look at it, same as xxx_init(). As I said in other answer: I'm not advocating to include C++ support in current kernel. I just say that the only valid argument is that 'KERNEL IS C', and interfacing C with C++ just would add bloat and errors. There is no technical argument to reject to write an OS kernel in C++. It would not be slower nor more complicated, and it will be probably safer because it leaves less things (from thost you always _must_ do) to programmers memories. -- J.A. Magallon <jamagallon()able!es> \ Software is like sex: werewolf!able!es \ It's better when it's free Mandriva Linux release 2006.1 (Cooker) for i586 Linux 2.6.16-jam9 (gcc 4.1.1 20060330 (prerelease)) #1 SMP PREEMPT Tue
Attachment:
signature.asc
Description: PGP signature
- Follow-Ups:
- Re: C++ pushback
- From: Barry Kelly <[email protected]>
- Re: C++ pushback
- References:
- C++ pushback
- From: Gary Poppitz <[email protected]>
- Re: C++ pushback
- From: Martin Mares <[email protected]>
- Re: C++ pushback
- From: "Jeff V. Merkey" <[email protected]>
- Re: C++ pushback
- From: Alan Cox <[email protected]>
- Re: C++ pushback
- From: "J.A. Magallon" <[email protected]>
- Re: C++ pushback
- From: Xavier Bestel <[email protected]>
- Re: C++ pushback
- From: Avi Kivity <[email protected]>
- Re: C++ pushback
- From: Martin Mares <[email protected]>
- Re: C++ pushback
- From: Avi Kivity <[email protected]>
- Re: C++ pushback
- From: Martin Mares <[email protected]>
- Re: C++ pushback
- From: Avi Kivity <[email protected]>
- Re: C++ pushback
- From: Xavier Bestel <[email protected]>
- C++ pushback
- Prev by Date: Disappearing ARP in /proc/net/arp
- Next by Date: RE: Problems with EDAC coexisting with BIOS
- Previous by thread: Re: C++ pushback
- Next by thread: Re: C++ pushback
- Index(es):