[Click] kernel patching elimination

[Konstantin Zaykalov]

Hi Cliff,

Thank you for such a detailed answer. The problem I see with Click at the
moment is that it is tied to a particular kernel version, the most recent
of which is 2.6.24.7, released in May 2008. So if I want to take advantage
of any recent feature of the kernel (such as ext4 filesystem, for example),
I need to upgrade my kernel, but Click patch can prevent me from doing so.

 If I ever make any changes to Click, I will definitely consider them to be
contributed back to the community.

There is one part of your answer I didn't quite undestand, though:

>On many versions of modern linux, kernel patching is not required, so I'm
not sure what you want to change.

Could you indicate, please, what are the versions of Linux, where kernel
patching is not required? It took me ages to find Linux version 2.6.24.7 (I
eventually had to use Wayback Machine @ web.archive.org to get it), so if
Click could work with modern Linux kernels without patching, it would be
great!

Thanks again!

Konstantin




On Thu, Nov 1, 2012 at 3:15 PM, Cliff Frey <cliff at meraki.com> wrote:

> On Thu, Oct 25, 2012 at 5:22 AM, Konstantin Zaykalov <zaykalov at gmail.com>wrote:
>
>> Hi,
>>
>> I've got a few questions regarding the design of Click router:
>> 1) Why does Click do kernel patching (and fixing include files via
>> fixincludes.pl script) for g++ compiler instead of providing wrapper
>> functions, surrounded by "extern "C" "? Or even some abstraction layer
>> written in C?
>>
>
> kernel patching works very well.  As Lars stated, it is not possible to
> directly include the kernel header files in a c++ file, for many different
> reasons (the "::" operator, use of variables name "new", etc).  If an
> abstraction layer was written in C, it would need to abstract *all* packet
> access, which means that reading or writing any packet data would require
> an extra layer of function calls, which would likely affect performance.
>
>
>> 2) Why doesn't Click use netfilter hooks for intercepting packets?
>>
>
> Depending on the version of linux, click will use many different hooks.
>  If you have a specific recommendation for something that would be better
> than the current hooks, patches would be appreciated!
>
>
>> 3) Why doesn't Click use NAPI for device polling?
>>
>
> Ethernet drivers use NAPI.  Click is not an ethernet driver.  The
> "PollDevice" click element, which acts as an ethernet driver, was written
> before NAPI existed.  It would probably be possible to build a high
> performance framework that gave packets directly to click by somehow
> leveraging NAPI like interfaces... it still might require compile time
> changes though.
>
> Basically I am looking into possibilities to eliminate kernel patching
>> altogether and make it more independent/standalone.
>>
>
> On many versions of modern linux, kernel patching is not required, so I'm
> not sure what you want to change.  Also, click can be run at userlevel in a
> very standalone fashion.
>
> Cliff
>
>