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 <[email protected]> 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 <[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
