[Click] C++ vs the kernel

[Roman Chertov]

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

Well I didn't consider the exception case.  I suppose mainly because I 
hate them and never use them.  For that matter, they are not used in the 
Click code that I have examined.  I think you can use exceptions as long 
as they don't lead to program termination.  When the kernel loads the 
proclikefs module which in turns loads the click module, the kernel 
interacts with these two modules through the standard interface.  The 
modules interact with the kernel through the standard interfaces as well.

I think if you use a "feature" of C++ that would result in a program 
termination you would get a crash in the kernel mode.  Hopefully Eddie 
can shed some light on this as I have never experimented with such 
scenarios (for obvious reasons).

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

This is true.  In Click there are allocation functions; they serve as 
wrappers for the kernel functions. (click_lalloc and click_lfree)

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

Possibly could have been extra headaches during linking.

Roman

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