[Click] C++ vs the kernel

[Eddie Kohler]

Etc., etc., etc.

Adam M wrote:
> 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?

The magic of type safe linking is that argument lists turn into part of 
the function names.  The kernel simply thinks you have differently named 
functions.  Nothing special is required
> 
> Also, what happens if you throw an exception in the kernel? What do you
> do if the constructor of an object fails?

No exceptions in kernel.

>> 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.

There isn't necessarily a good reason.  Some mediocre reasons:
1. Less-good STL support available when we began the project
2. We didn't understand/respect the STL as much when we began the project
3. STL containers sometimes use exceptions, which are not allowed in the 
kernel
4. Inertia

Nevertheless Click String/Vector should be generally STL compatible. 
Any deviations are bugs.

>> 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?

They are certainly useful for that purpose.  However, the kernel will 
also process all packets that are handed to KernelTap/Tun.  One would 
need to install firewall rules telling the kernel to ignore the packets 
  except to send them to KernelTap/Tun.  I'd love to include an element 
that did this automatically, if someone wrote one.

> 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.

That's why the code is available!

Eddie