2012/2/1 David Miller <[email protected]>:
> From: Štefan Gula <[email protected]>
> Date: Wed, 1 Feb 2012 00:32:04 +0100
>
>
> You don't understand.
>
> If your code is superfluous in the end, we shouldn't add it in
> the first place.
>
> But if I do relent and let your code in now, we have to live
> with it, and it's associated maintainence costs, FOREVER.
>
> That's why I'm forcing this to be implemented properly from the start,
> so we don't end up with two pieces of code that provide essentially
> the same functionality.
I understand your strategic point of maintenance here and partially
agree with it. And if I understand it correctly, it is to one day have
openvswitch as full replacement of linux bridge code. On the other
hand gretap interface already exists in kernel so that part of the
code is currently also superfluous - what's the plan with that
particular piece of code?. So if this is now only about the
maintenance of my code, I'll be more than happy to continue
maintaining it myself together with you guys. And if it comes in the
future to decision to remove whole gretap code (not just my part) and
replace it with something else that will provide the same or even more
functionality, I have absolutely no problem with that.
From: ?tefan Gula <[email protected]>
Date: Wed, 1 Feb 2012 08:22:02 +0100
> So if this is now only about the
> maintenance of my code, I'll be more than happy to continue
> maintaining it myself together with you guys.
You have a very warped understanding of what maintainence cost means.
Everyone time someone wants to change a core API in the networking
your new code will need to be considered. Every time someone wants to
audit how an interface is used, your code adds to the audit burdon.
And this is burdon placed upon other people, even if you personally
"promise" to maintain this specific code snippet. This promise
completely meaningless from a global kernel maintainence standpoint.
More code has a cost, no matter how well that specific piece of code
is maintained.
Therefore we don't add supurious code, and your code is spurious if it
will end up duplicating a more desirable implementation and interface
for this functionality.
The world has spun successfully countless times in the 18 years that
Linux hasn't had support for the feature you are so gravely interested
in including "right now", and I suspect it will spin successfully a
few more times while a proper implementation is ironed out.
2012/2/1 David Miller <[email protected]>:
> From: Štefan Gula <[email protected]>
> Date: Wed, 1 Feb 2012 08:22:02 +0100
>
>> So if this is now only about the
>> maintenance of my code, I'll be more than happy to continue
>> maintaining it myself together with you guys.
>
> You have a very warped understanding of what maintainence cost means.
>
> Everyone time someone wants to change a core API in the networking
> your new code will need to be considered. Every time someone wants to
> audit how an interface is used, your code adds to the audit burdon.
That's true. But as I said. gretap interface already exists in linux
kernel. Without my patch it simply use logic of point-to-point tunnel
or static point-to-multipoint tunnel using muticast IP address as
destination. The point here is that the maintenance cost is there
already:
>From the kernel API point of view the functions that enables use of
gre or gretap interface are already there maintained (functions like
init/exit/xmit/receive...). That part of the code was modified as
little as possible. If that kernel API changes, the API will need to
be changed also for standard gre or gretap code, which in the end
almost the same amount of time consumed to figure out the code as it
is the same functions that are called.
>From the user-space/netlink API point of view those functions
(open/close/add/change/del....) are already maintained - my patch
allows you to use only one additional keyword "bridge" to maintain
backward compatibility, so if that part of API changes, it influences
again whole gre/gretap API and therefore almost the same amount of
code is needed to be checked.
The last portion of auditing the code purpose is that you are
developing something new that doesn't exists or try to port the code
to somewhere else. In that time we are talking about maintaining the
gre/gretap code itself and not some global API changes - that's the
only one relevant where more time is needed, but this one is expected
(at least should be by developer)
If I missed something, please feel free to highlight it.
>
> And this is burdon placed upon other people, even if you personally
> "promise" to maintain this specific code snippet. This promise
> completely meaningless from a global kernel maintainence standpoint.
Yes, the burdon is there, but it's minimal from global point of view.
> Therefore we don't add spurious code, and your code is spurious if it
> will end up duplicating a more desirable implementation and interface
> for this functionality.
It cannot duplicate something that doesn't actually currently exists.
VXLAN or NVGRE are still in process of developing/designing, so in the
end it could easily happen that those "standards" will not do the same
thing or by the same methodology - it's completely on those
developers/designers, if they adopt my implementation/design or use
something else. Openvswitch gre interface is currently only the same
as thing as is current gretap interface in linux kernel with some kind
of caching code - nothing more.
2012/2/1 Štefan Gula <[email protected]>:
> 2012/2/1 David Miller <[email protected]>:
I think that everything what could be done and said from my-side to
provide you guys answers to hopefully all your questions and to get
this into kernel was done. So I would like to ask you to provide me
final feedback. Thanks
2012/2/7 Štefan Gula <[email protected]>:
> 2012/2/1 Štefan Gula <[email protected]>:
>> 2012/2/1 David Miller <[email protected]>:
> I think that everything what could be done and said from my-side to
> provide you guys answers to hopefully all your questions and to get
> this into kernel was done. So I would like to ask you to provide me
> final feedback. Thanks
>
>
After staring at your message over ten minutes I have to say that
you really need to stop overnight work ASAP and take a hot shower and
a cup of hot coffee, then try to sort out answer to my question, what
Ingo Molnar did, like ANK and old David, in the past ten years, and how?
From: ?tefan Gula <[email protected]>
Date: Tue, 7 Feb 2012 10:10:04 +0100
> 2012/2/1 ?tefan Gula <[email protected]>:
>> 2012/2/1 David Miller <[email protected]>:
> I think that everything what could be done and said from my-side to
> provide you guys answers to hopefully all your questions and to get
> this into kernel was done. So I would like to ask you to provide me
> final feedback. Thanks
Your patch will not be applied, you haven't said anything new to me,
you haven't given me any new information that would change my position,
so it should be no surprise to you that I still want you to work
towards a solution that uses openvswitch.
And btw, your inability to see our point of view on this matter in any
way, shape, or form, is really working to your disadvantage and is
undermining your ultimate goals. Your should seriously reconsider
how you are going about this, because right now I cringe when I see
messages from you in my inbox and I bet a lot of other people feel
this way right now as well.