lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160708011754.GI2279@X58A-UD3R>
Date:	Fri, 8 Jul 2016 10:17:54 +0900
From:	Byungchul Park <byungchul.park@....com>
To:	SeongJae Park <sj38.park@...il.com>
Cc:	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	David Howells <dhowells@...hat.com>,
	Minchan Kim <minchan@...nel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Jonathan Corbet <corbet@....net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-doc <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v4 3/3] Doc/memory-barriers: Add Korean translation

On Fri, Jul 08, 2016 at 07:50:39AM +0900, SeongJae Park wrote:
> > I will add my opinion in korean.
> 
> Thank you for kind and faithful review.  I agree with most of your opinions and
> suggestions.  Most of your suggestions looks much better than mine.
> 
> However, I also have some different opinion.  I want to emphasize the fact that
> (1) CPUs 'issue' memory operations to memory system as they want, (2) memory
> system 'executes' those operations as they want, and (3) CPUs 'perceive' the
> 'effects' of the operation executions as they want.  I want to emphasize the
> fact in document because I think most confusion about memory ordering comes
> from vague understanding about the relation.  To my perspective, few of your

Right. I agree with you.

> suggestions could enhance readability but could dim the point, too.  I have
> appended the opinion in Korean line by line, too.  So, if you do not opposed
> to, I will enhance the text again while keeping the point.

...

> >> +
> >> +     STORE *A = 5, x = LOAD *D
> >> +     x = LOAD *D, STORE *A = 5
> >> +
> >> +두번째 조합은 데이터를 읽어온 _후에_ 주소를 설정하므로, 잘못된 동작을 일으킬
> >> +것입니다.
> >> +
> >> +
> >> +보장사항
> >> +--------
> >> +
> >> +CPU 에게 기대할 수 있는 최소한의 보장사항 몇가지가 있습니다:
> >> +
> >> + (*) 어떤 CPU 든, 의존성이 존재하는 메모리 액세스들은 해당 CPU 자신에게
> >> +     있어서는 해당 순서 그대로 요청됩니다. 즉, 다음에 대해서는:
> >
> > 요청됩니다. -> 수행됩니다.
> 
> CPU (또는 디바이스) 는 메모리 오퍼레이션을 메모리 시스템에 '요청'하고 메모리
> 시스템에 의해 '수행'된 오퍼레이션의 '결과'를 '받거나' 다른 CPU 가 요청해서
> 메모리 시스템에서 수행된 오퍼레이션의 영향을 받게 되는 것인데, (1) CPU 가
> 코드와 순서를 바꿔서 요청할 수 있고, (2) (캐시를 포함한) 메모리 시스템이 요청된
> 오퍼레이션들을 임의의 순서로 수행할 수 있고, (3) 메모리 시스템의 수행 결과를 각
> CPU 가 임의의 순서로 볼 수 있게 된다 는 점이 메모리 순서 규칙의 기본이고,
> 원문에 깔려 있는 기본 바탕이라 이해하고 있습니다.
> 
> 이 경로를 단순하게 '수행한다'고 하게 되면 이 느낌을 헷갈리게 할 수도 있을 것
> 같아서, 가능한 CPU 는 '요청' 하고 메모리 시스템으로부터 결과를 '전달받는다'는
> 느낌을 문서 전체적으로 유지하는게 어떨까 싶습니다.

Yes. Agree.

> 이 문장의 경우 그냥 '요청'한다고 하니까 좀 어색한 것 같은데, 메모리 시스템에게
> 요청한다는 점을 좀 더 강조하는 식으로 수정하도록 하겠습니다.

Agree. And it seems to be not easy :(

> >> +
> >> +     Q = READ_ONCE(P); smp_read_barrier_depends(); D = READ_ONCE(*Q);
> >> +
> >> +     CPU 는 다음과 같은 메모리 오퍼레이션들을 요청합니다:
> >
> > (...) 아래 메모리 오퍼레이션을 수행합니다:
> 
> 역시 '요청'의 느낌은 살리도록 하겠습니다.

Yes.

> >> + (*) 특정 CPU 내에서 겹쳐서 행해지는 로드와 스토어 들은 그 CPU 안에서는 순서가
> >
> > 메모리 영역이 겹치는 로드와 스토어가 한 CPU 내에서 수행될 경우, 해당 CPU
> > 내에서 보았을 때에 그 순서는 바뀌지 않습니다. (...)
> 
> 역시 '요청' 의 느낌은 남기도록 하겠습니다.

Yes.

> > -> 해당 CPU는 오직 다음 순서대로 메모리 오퍼레이션을 수행할 것입니다.
> 
> 역시 '요청' 의 느낌은 남기도록 하겠습니다.

Yes.

> >> +     a = LOAD *X, STORE *X = b
> >> +
> >> +     그리고 다음에 대해서는:
> >> +
> >> +     WRITE_ONCE(*X, c); d = READ_ONCE(*X);
> >> +
> >> +     CPU 는 오로지 다음의 명령만을 냅니다:
> >
> > (...) 오로지 아래 순서로 수행합니다.
> 
> 역시 '요청' 의 느낌은 남기도록 하겠습니다.

Yes.

> > I think there are still many things literally translated. It makes it much
> > harder to read.
> >
> > I think it's not the version with which I can add opinions line by line.
> > Please review all sentences line by line carefully by yourself and make it
> > more readable.
> >
> > I hope you don't hurry and spend more time to make it done. I believe you
> > agree with it.
> 
> Ok, I agree with your opinion.  Actually, I have reviewed all sentences line by
> line for this version, too.  However, it looks like it wasn't sufficient.  I
> will enhance it again.

Thank you,
Byungchul

> 
> >
> > Thank you,
> > Byungchul

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ