[Click] C++ vs the kernel

[Roman Chertov]

Adam M wrote:
> Hi folks,
> 
> Sorry for the self-reply, but I thought a follow-up was in order.
> 
> I had no idea when I originally posted that this was such a sensitive
> topic, as is overwhelmingly apparent from the following thread:
> http://kerneltrap.org/node/2067

There was a nice discussion on the e2e list about the qualifications of 
Linux developers in regards to TCP...

> 
> I certainly don't want any discussion ensuing from my question to
> devolve into anything like that LKML thread. So, let me rephrase my
> question a bit.
> 
> It is clear that even though Click elements are written in C++, many of
> the features of C++ must be avoided and disabled in order to maintain
> compatibility with the kernel. That said, it is certainly encouraging
> that the Click community seems to have been quite successful so far.

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.

> 
> However, I can't imagine we got to this point without many Element
> implementers hitting "gotchas" that caused subtle bugs when linking with
> the kernel. What I'm hoping is that these gotchas are documented

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

> somewhere so that new developers don't have to unnecessarily suffer the
> same pains as the original developers must have. In other words, is
> there a "best practices" guide, or a "Thou shalt" and "Thou shalt not"
> list? It seems that going to LKML and asking "Can you help me write C++
> for the kernel?" is going to invite another flame war like the one I
> mentioned earlier. 

You use C functions to interact with the kernel but the kernel is 
unaware that you are using C++.  I have successfully created device 
drivers that are part of Click, but from the kernel point of view are 
regular char devices.

> 
> Also, I am a little confused by the following statement from the
> above-mentioned LKML thread: "The router code of the project works both
> in userspace and in kernel-space. It just works much slower in
> userspace."

If you are in userspace you get user space scheduling priority.  Simple 
as that.

> 
> I thought that userspace mode utilizes a Berkeley Packet Filter
> (something like Pcap) that is completely passive, and cannot affect how
> packets are processed in the kernel. So I don't understand the statement
> that you can do either kernel-space or userspace, but userspace is
> slower. It seems that running in userspace is a severely crippled mode
> of operation.

If you are just doing passive packet inspection there is no need to run 
in the kernel.  If you decide to run in the kernel, there are complex 
tasks that you must deal with (passing packets to/from the kernel) and 
for some projects it is just not worth it.

> 
> In my particular project, I don't need incredible speed, so if it is
> true that I can accomplish everything (or close to) in userspace that I
> could have in kernel (just slower), I might just go that way. Just
> having to install a patched kernel is reason enough to make me wary of
> working in kernel-space when I don't really need the speed.

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

Hopefully this helps.

Roman

> 
> Thanks again,
> Adam
> _______________________________________________
> click mailing list
> click at amsterdam.lcs.mit.edu
> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>