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 <[email protected]>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 <[email protected]> wrote: > > > On Thu, Oct 25, 2012 at 5:22 AM, Konstantin Zaykalov <[email protected] > >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 > [email protected] > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
