cvs commit: src/sys/amd64/amd64 pmap.c src/sys/i386/i386 pmap.c

[Stephan Uphoff]

Yar Tikhiy wrote:
> On Thu, Apr 26, 2007 at 02:41:02AM -0600, Scott Long wrote:
>   
>> Yar Tikhiy wrote:
>>     
>>> On Thu, Apr 26, 2007 at 12:42:14AM -0600, Scott Long wrote:
>>>       
>>>> Yar Tikhiy wrote:
>>>>         
>>>>> On Wed, Apr 25, 2007 at 02:41:00PM -0400, Stephan Uphoff wrote:
>>>>>           
>>>>>> Yar Tikhiy wrote:
>>>>>>             
>>>>>>> On Sat, Apr 21, 2007 at 09:54:12AM -0600, Coleman Kane wrote:
>>>>>>>
>>>>>>>               
>>>>>>>> On Sat, 2007-04-21 at 17:03 +0200, Andre Oppermann wrote:
>>>>>>>>  
>>>>>>>>                 
>>>>>>>>> Stephan Uphoff wrote:
>>>>>>>>>    
>>>>>>>>>                   
>>>>>>>>>> ups         2007-04-21 14:17:30 UTC
>>>>>>>>>>
>>>>>>>>>> FreeBSD src repository
>>>>>>>>>>
>>>>>>>>>> Modified files:
>>>>>>>>>>  sys/amd64/amd64      pmap.c 
>>>>>>>>>>  sys/i386/i386        pmap.c 
>>>>>>>>>> Log:
>>>>>>>>>> Modify TLB invalidation handling.
>>>>>>>>>>
>>>>>>>>>> Reviewed by:    alc@, peter@
>>>>>>>>>> MFC after:      1 week
>>>>>>>>>>      
>>>>>>>>>>                     
>>>>>>>>> Could you be a bit more verbose what changed here and why it
>>>>>>>>> was done?
>>>>>>>>>
>>>>>>>>>    
>>>>>>>>>                   
>>>>>>>> I agree. I would really like to know what the modification 
>>>>>>>> accomplishes.
>>>>>>>>  
>>>>>>>>                 
>>>>>>> Alas, we don't live in an ideal world.  If we did, our commit
>>>>>>> messages would always follow the well-known guideline:
>>>>>>>
>>>>>>> 0. Tell the essence of the change.
>>>>>>> 1. Give the reason for the change.
>>>>>>> 2. Explain the change unless it's trivial.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> In the ideal world there are no NDAs :-)
>>>>>>             
>>>>> Was the change based on a document under NDA?  Then this case raises
>>>>> an interesting question: to what extent an open source developer
>>>>> is allowed to explain his code that was based on a document under
>>>>> NDA?  Of course, it should depend on the NDA, but I suspect that a
>>>>> typical NDA requires a lawyer to interpret it unambiguously (I've
>>>>> never signed one by myself), and an overcautious lawyer would say
>>>>> that the open source code itself violates the NDA because anybody
>>>>> can RTFS. :-)
>>>>>
>>>>>           
>>>> Wow, that was painful to read.  NDAs that specifically allow source
>>>> code licensing and distribution are quite common.  They even get written
>>>> and reviewed by lawyers! =-)
>>>>         
>>> It's a good news!  But what about explaining the code to the public?
>>>
>>> - Mr. Developer, why does it take an ugly hack to make the device work?
>>> - Can't tell ya, I'm under NDA.
>>>
>>>       
>> I think you have to respect that John and Stephan were doing the right 
>> thing with this.  This was no different than a security fix that gets
>> committed before the vulnerability is disclosed.  No one seems to get
>> upset that the security team operates this way.
>>     
>
> John and Stephan are doing a great job in any case, but I fail to
> understand your point.  I can't see how the two cases can be the
> same.  A fixed vulnerability is no more a threat to security, but
> NDA doesn't get cancelled upon the commit.  So I was curious about
> how much knowledge a developer is legally allowed to relay to the
> community besides the code itself if he is tied by NDA.
>
>   
In this specific case the vendor was really helpful and just wanted to 
give us a chance
to fix the code before publishing the documentation that described why 
it was needed.
The vendor worked with me to get the fix in the tree before the document
publication date and as such there was no problem with the NDA.
Yesterday the vendor published the documentation and as planned I could 
then comment
on why the changes were needed.

In general I agree that source code written with documents under NDAs  
can not be
fully understood/verified without access to these documents and as such does
not fully benefit from the automatic open source review process.
And I am really happy that now that the relevant document is published 
everyone can
review my changes.

Stephan