Re: kernel patching elimination

Hi Lars,
Yes, I agree, an abstraction layer is not an easy job (otherwise it would
have probably been already done). However it is achievable for example
through a combination of own data structures that map to kernel data
structures and through functions that somewhat correspond to kernel
functions. Obviously all constant variables and primitive data types need
to be taken care of as well. This would eliminate the need to include linux
header files, over which you have no control. Obviously such an approach
will incur some performance penalty.
I think that this question is aimed primarily at Click architects (Eddie
Kohler?), I am simply wondering if the options I wrote about were ever
considered (I'd imagine they were), maybe someone has done some research
around this topic and found some really serious obstacles that make this a
non-starter, for example.
Regards,
Konstantin

On Fri, Oct 26, 2012 at 6:59 AM, Lars Bro <[email protected]> wrote:

> Hi Konstantin
>
> At least with include files, they are "included" and cannot easily be
> abstracted away. If they contain syntax that is not C++, and are to be
> included into C++ modules, then we got the problem. For example  the use of
> the :: operator.
>
> So the way to deal with it is to run fixincludes.pl, fixing these
> particular problems, providing  a local set of include files.
>
> fixincludes.pl at least documents what include file problems are solved.
>
> yours,
> Lars Bro
>
> On Thu, Oct 25, 2012 at 2:22 PM, 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?
>> 2) Why doesn't Click use netfilter hooks for intercepting packets?
>> 3) Why doesn't Click use NAPI for device polling?
>>
>> Basically I am looking into possibilities to eliminate kernel patching
>> altogether and make it more independent/standalone.
>>
>> Thank you,
>>
>> Konstantin
>> _______________________________________________
>> click mailing list
>> [email protected]
>> https://amsterdam.lcs.mit.edu/mailman/listinfo/click
>>
>
>