[Click] kernel patching elimination

[Cliff Frey]

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
>