[Click] C++ vs the kernel

[Adam M]

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

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.

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

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

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.

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.

Thanks again,
Adam