[Click] C++ vs the kernel

[Adam M]

On Tue, 24 Jul 2007 14:52:31 -0400, "Roman Chertov"
<rchertov at purdue.edu> said:
> In my experience you can use all the "features" of C++ inside the 
> elements without much concern about compatibility.  Usually the problem 
> arises when you include some C header and a struct will have a member 
> called "private".  That requires an imaginative solution or a patch to 
> the kernel.

I don't understand how this can be true. What would happen if you had
the two functions with the same name, but with a different argument
list?

Also, what happens if you throw an exception in the kernel? What do you
do if the constructor of an object fails?

Again, I'm not a kernel expert, but I thought there were more
limitations on memory allocations than there are in userspace. 

The following comment was made on the LKML thread: "Inside the kernel
you need to be very careful about HOW you allocate membory depending on
what type of context you're in (interrupt vs userland primarily; plus
certain types of I/O processing have extra requirements) Since so much
extra care is required I think that anything that makes
allocation/deallocation more automatic is really asking for subtle
bugs."


> As long as you don't use C++ libs and use data structures 
> (strings,lists, etc) implemented by Click there should be no issues.

Yeah, a colleague referred me to these after my last post. The thing I
don't understand here is why the same thing could not have been
accomplished using a custom allocator for the standard STL containers?
I'm sure there's a good reason, but at first glance I can't think of
what it is.


> Userspace elements are easier to debug too :)  No change to make an oops.

Of course, which is why I'd like to stick to userspace if possible (at
least for now).

Is the reason that 'KernelTap' and 'KernelTun' exist to provide a way
for a user-space application to directly manage a network interface? Is
this the intended way for user-space applications to be active without
being in the kernel?

I'll admit, Eddie Kohler's thesis is certainly informative, but it's
already 6-7 years old. I often think to myself while I'm reading it "I'm
wondering if this is still true", or if something important has happened
since that is completely unmentioned in the thesis.

Thanks again,
Adam