[Click] kernel patching elimination

[Konstantin Zaykalov]

Hi Cliff,

Thank you for the hint - I have now noticed that Click should support
patchless install. This is exactly what I was looking for. It still fails
for me, but I'll figure it out.

Thanks!

Konstantin


On Fri, Nov 2, 2012 at 10:56 PM, Cliff Frey <cliff at meraki.com> wrote:

> Have you tried just building click on your system's kernel?  I believe
> that it works on all modern linux kernels.
>
> On Fri, Nov 2, 2012 at 4:42 AM, Konstantin Zaykalov <zaykalov at gmail.com>wrote:
>
>> 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
>> >
>> >
>> _______________________________________________
>> click mailing list
>> click at amsterdam.lcs.mit.edu
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>
>
>