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

Hans Petter Selasky hps at selasky.org
Thu Jan 22 10:06:27 UTC 2015


On 01/22/15 10:49, K. Macy wrote:
>>> 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.
>

Hi Kip,

That is fine by me. I didn't know about the "protocol" you refer to 
until now. I will revert my callout patch and hopefully without causing 
any build issues and then we can have another round in the Phabricator 
to iron out the TCP stack issues and possibly others. Sounds good. 
Please give me some hours to ensure that the pullout doesn't cause any 
build breakages.

Thank you!

--HPS



More information about the svn-src-head mailing list