svn commit: r277213 - in head: share/man/man9 sys/kern sys/ofed/include/linux sys/sys

[K. Macy]

>> Sigh, you still do not understand.  It is your duty to identify all pieces
>> which break after your change.  After that, we can argue whether each of
>> them is critical or not to allow the migration. But this must have been
>> done before the KPI change hit the tree.
>>
>
> Hi,
>
> Are you saying that pieces of code that runs completely unlocked using
> "volatile" as only synchronization mechanism is better than what I would
> call a temporary and hopefully short TCP stack performance loss?
>


Hans - The project has long standing expectations about how changes
are made to core subsystems. When you hear "understand" your ego
intercedes - put that aside. I told you this first this afternoon and
others have repeated it several times. When you change a KPI,
consumers are updated at the same time - _period_. This protocol is
not up for debate. I'm glad that others have the presence of mind and
fortitude to insist on this. Your work is appreciated, but whether or
not you agree about this is not relevant.

We're all sorry if this upsets you but this is only a temporary
setback. Channelling this work through phabricator will go a long way
towards smoothing over the current friction. Think about the greater
goal here, not whether this is "done" now or in a week.

-K