발생한 문제를 둘 모두가 긍정적이고 적극적인 자세로 풀어가라. 인내하지 마라.

‘부부 사이에는 어떤 문제든 늘 일어난다. 그게 살아 있는 부부다. 원만하고 건강한 부부란, 아무 문제가 없는 부부가 아니라 발생한 문제를 두 사람 모두 긍정적이고 적극적인 자세로 풀어 가는 부부다. 물론 싸움에만 집착하여 서로 잘잘못을 가리는 것도 문제다. 하지만 정반대로 세월이 약이라고 인내만을 미덕으로 삼는 것도 잘못이다. 인내는 좋은 미덕이 틀림없으나 모든 걸 해결해 주지는 못한다. “어차피 대화도 안 통하는데 내가 참지”라고 침묵한다면 문제는 더욱 심각하다.’

“나는 죽을 때까지 재미있게 살고 싶다” 290p.

어찌 부부 관계만 이러랴.

말을 할 때 명심할 열가지 조언

‘말을 할 때는 다음의 열 가지를 명심하라.

첫째, 상스러운 말은 하지 마라. 욕이나 비하하는 말은 말 가운데 가장 낮은 하수다.
둘째, 상대가 제일 싫어하는 말은 절대 하지 마라. 누구나 정말 듣기 싫은 말이 있다. 그 말은 뇌관이다. 건드리면 폭발한다.
셋째, 남과 비교하는 말은 피하자. 세 살 먹은 아이부터 팔십 살 먹은 노인까지, 남과 비교하면 정말 기분 나쁘다.
넷째, 인격을 무시하는 말로 공격하지 마라. 자존심을 건드리면 관계를 회복하기 어렵다. 두고두고 원망만 들을 뿐이다.
다섯째, 상대 가족을 헐뜯지 마라. 본질과는 아무 상관도 없는 상대의 가족은 어떤 상황에서도 건드리지 마라.
여섯째, 폭탄선언은 제발 참아라. ‘우리 헤어져’, ‘이혼하자’, ‘사표내야지’ 등 이런 이야기는 정말 마지막에 하는 말이다.
일곱째, 유머 있는 대화의 기술이 필요하다. 무슨 이야기든 심각할 필요는 없다.
여덟째, 분명한 말은 오해를 남기지 않는다. 확실한 ‘예스’와 확실한 ‘노’는 연습해야 잘할 수 있다.
아홉째, 비비 꼬는 꽈배기 말은 하지 마라. 마음이 꼬여 있을 때는 침묵하는 게 낫다.
열째, 사람을 죽이는 독 있는 말도 있다. 말은 세상에서 가장 무서운 독이 되기도 하고 명약이 되기도 한다.’

“나는 죽을 때까지 재미있게 살고 싶다” 안의 “말실수를 하고 후회한 적이 많은 사람들에게” 222~223p.

나도 경험으로 얻었던 몇가지 조언에 더해서 구구절절 맞는 조언들. 뼈저리다.

상대의 특별한 점을 기억하라

‘대놓고 “당신은 무슨 일을 잘 하냐”고 묻기도 한다. 보통 사람들은 그런 질문에 답하기를 좋아하고, 질문을 한 상대방에게 호감을 가진다’

‘자, 50여 년 경력의 정신과 의사가 일러 주는 인간관계의 비결은 상대의 특별한 점을 기억하라는 것이다.’

“나는 죽을 때까지 재미있게 살고 싶다” 220~221p.

좋은 질문이다. 답하는 사람이 흥이 나는 질문이니까. 질문자에게 호감이 생기는 것이 당연하다.

좋은 질문 하니까 생각나는데, 얼마 전 누군가가 지인들에게 “너는 내가 왜 좋아?”라고 자주 묻는단 이야기를 들었다. 이 또한 좋은 질문이다.
답변자는 일단 질문자를 내가 좋아하는가-질문자에 대해서- 생각할테고, 질문자를 좋아한다면, 그 이유에 대해 생각해 볼 것이고, 이를 말로 할테니까.
좋아하지는 않더라도 그와의 관계를 해치기 싫은 사람이라면 이유는 어찌됐던 이래서 좋다고 말로 할테니까.
그를 싫어하는 사람이라면, 그리고 질문자가 답변자가 자신을 좋아한다고 오해하고 있었다면 그게 아님을 알 수 있을테니까.
그를 싫어하는 사람에게, 그리고 질문자가 그 사실을 알고 있다면 저 질문이 나오지 않겠지.
어떠한 것을 밖으로 꺼내어 말로 하는 것은 큰 차이를 일으킨다. 사실일 경우, 생각이 더 확고해지고, 사실이 아닐 경우는 자기합리화의 과정을 거치기 때문이다. 그래서 말이 결국 사실-여기선 질문자를 좋아한다는 사실-이 된다.

상대의 특별한 점을 기억하라는 건 디테일의 힘과도 상통한다. 상세하게 나를 기억하는 사람이 어찌 싫을까.

이러나 저러나, 호감의 이야기를 보고 예전의 내가 생각나서 적는다. 난 오래전 아마 모두의 사랑을 받고 싶었던 것 같다. 나를 싫어하는 사람도 나를 좋아하게 하고 싶었던 것 같다. 그래서 내가 먼저 내민 손을 받아주지 않는 상대를 서운해하고, 원망했고, 이해할 수 없었다. 나중에서야 내 욕심임을 알았지만.
요즘은 나를 싫어해도, 내가 먼저 내민 손을 치워도 그냥 그러려니 한다. 그럴 수 있음이다. 사람 맘은 내 맘대로 되는 것이 아니다. 그저 조용히 손을 다시 거둘 뿐이다.

최선을 다하지 말고, 여력을 남겨라

‘나는 ‘최선’이라는 말이 싫다. 최선은 내가 가진 100을 다 쓰라는 말이다. 그러면 씨앗을 먹어 치운 농부처럼 내일을 기약할 수 없게 된다.’

‘이 많은 일을 할 수 있었던 것은 늘 나의 능력을 30퍼센트 가량 아껴 두었기 때문이다.’

“나는 죽을 때까지 재미있게 살고 싶다” 안의 “내가 ‘최선을 다하라’라는 말을 싫어하는 이유”

난 이 깨달음이 늦었다. 입사하고 한창 의욕이 과해 잠도 안자고, 몸 깎아가며 일하던, 내가 맡지 않아도 될 몫까지 끌어 안고, ‘책임감’이란 단어에 취해서 나를 태우던 그 때, 지친 나를 다른 부서의 한 선임님은 ‘기름을 채워야 또 달리지. 기름도 안채우고 계속 달리면 멈춰요’라며 반강제로 스타벅스로 데려가 한가로이 라떼를 먹였다.

여력을 남겨라. 남는 힘이 없으면 모든 일이 귀찮아진다. 그 일 외에 아무 것도 할 수 없게 된다. 그리고 그 남는 일들이 점점 쌓인다. 정말 돌이킬 수 없게 된다. 건강을 해치는건 덤이다. 그런데 그 덤을 얻으면, 네 인생 전체가 사라진다.

타인의 관심 부재를 당연시 하고, 외로움에 적응하기

난 왜 벌써 이미 노후 대비라는 걸 겪어 본 거 같을까. 🙂

‘노후 대비로 외로움에 대비하는 일도 잊어서는 안된다. 살다 보면 아무도 나에게 관심을 갖지 않는 시기가 꼭 온다. 그 상태를 당연하게 받아들이고 그에 적응하는 법은 스스로 찾아내야 한다.’

“나는 죽을 때까지 재미있게 살고 싶다.” 30p.

[ARM] Cortex-A 페이징

ARM Cortex-A 페이징에 대해서 잘 적혀있는 글 발견!
설명하면서 쓴 단어의 정의들도 정확하다. 설명도 간략하면서 쉽게 되어 있다.

http://kth3321.blogspot.kr/search?q=ARM+Cortex-A+%ED%8E%98%EC%9D%B4%EC%A7%95 

아참, 본문의 내용 중 예제에 Offset에 따른 물리 주소를 그저 Offset을 더하는 것으로 설명되어져 있는데, 이 부분은 잘못된 것으로 보인다. 실제로는 32비트 주소 값 혹은 pgd/pte 의 주소+a를 갖고 있으므로 Base + Offset * 4(=32 bits) 의 물리 주소를 참조한다.

[Linux:Kernel] AArch64 리눅스의 메모리 배치

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

Documentation/arm64/memory.txt

     AArch64 리눅스의 메모리 배치
     ============================

Author: Catalin Marinas <catalin.marinas@arm.com>
번역  : 양정석 <dasomoli@gmailREMOVETHIS.com>
Date  : 20 February 2012

이 문서는 AArch64 리눅스 커널이 사용하는 가상 메모리 배치를 설명합니다.
이 아키텍처는 4KB 페이지 크기의 4단계 변환 테이블과 64KB 페이지 크기의
3단계 변환 테이블을 허용합니다.

AArch64 리눅스는 유저와 커널 양 쪽 모두 39비트 (512GB) 가상 주소를 허용하는
4KB 페이지 설정의 3단계 변환 테이블을 사용합니다. 64KB 페이지는 오직
2단계 변환 테이블이 사용되지만 메모리 배치는 같습니다.

유저 주소는 63:39 비트가 0으로 셋팅되는 반면, 커널 주소는 같은 곳의 비트에
1로 셋팅됩니다. TTBRx 선택은 가상 주소의 비트 63에 의해 결정됩니다.
swapper_pg_dir은 오직 커널 (전역) 맵핑만 포합하는 반면,
유저 pgd는 오직 유저 (비전역) 맵핑만 포함합니다. swapper_pgd_dir 주소는
TTBR1으로 쓰여지고, TTBR0로 절대 쓰여지지 않습니다.


4KB 페이지의 AArch64 리눅스 메모리 배치:

시작 크기 용도
———————————————————————–
0000000000000000 0000007fffffffff 512GB 유저

ffffff8000000000 ffffffbbfffeffff ~240GB vmalloc

ffffffbbffff0000 ffffffbbffffffff  64KB [guard page]

ffffffbc00000000 ffffffbdffffffff   8GB vmemmap

ffffffbe00000000 ffffffbffbbfffff  ~8GB [guard, 추후 vmmemap]

ffffffbffa000000 ffffffbffaffffff  16MB PCI I/O 공간

ffffffbffb000000 ffffffbffbbfffff  12MB [guard]

ffffffbffbc00000 ffffffbffbdfffff   2MB 고정 맵핑

ffffffbffbe00000 ffffffbffbffffff   2MB [guard]

ffffffbffc000000 ffffffbfffffffff  64MB 모듈들

ffffffc000000000 ffffffffffffffff 256GB 커널 논리 메모리 맵


64KB 페이지의 AArch64 리눅스 메모리 배치:

시작 크기 용도
———————————————————————–
0000000000000000 000003ffffffffff   4TB 유저

fffffc0000000000 fffffdfbfffeffff  ~2TB vmalloc

fffffdfbffff0000 fffffdfbffffffff  64KB [guard page]

fffffdfc00000000 fffffdfdffffffff   8GB vmemmap

fffffdfe00000000 fffffdfffbbfffff  ~8GB [guard, 추후 vmmemap]

fffffdfffa000000 fffffdfffaffffff  16MB PCI I/O 공간

fffffdfffb000000 fffffdfffbbfffff  12MB [guard]

fffffdfffbc00000 fffffdfffbdfffff   2MB 고정 맵핑

fffffdfffbe00000 fffffdfffbffffff   2MB [guard]

fffffdfffc000000 fffffdffffffffff  64MB 모듈들

fffffe0000000000 ffffffffffffffff   2TB 커널 논리 메모리 맵


4KB 페이지의 변환 테이블 탐색:

+——–+——–+——–+——–+——–+——–+——–+——–+
|63    56|55    48|47    40|39    32|31    24|23    16|15     8|7      0|
+——–+——–+——–+——–+——–+——–+——–+——–+
 |                 |         |         |         |         |
 |                 |         |         |         |         v
 |                 |         |         |         |   [11:0]  페이지 내의 오프셋
 |                 |         |         |         +-> [20:12] L3 인덱스
 |                 |         |         +———–> [29:21] L2 인덱스
 |                 |         +———————> [38:30] L1 인덱스
 |                 +——————————-> [47:39] L0 인덱스 (미사용)
 +————————————————-> [63] TTBR0/1


64KB 페이지의 변환 테이블 탐색:

+——–+——–+——–+——–+——–+——–+——–+——–+
|63    56|55    48|47    40|39    32|31    24|23    16|15     8|7      0|
+——–+——–+——–+——–+——–+——–+——–+——–+
 |                 |    |               |              |
 |                 |    |               |              v
 |                 |    |               |            [15:0]  페이지 내의 오프셋
 |                 |    |               +———-> [28:16] L3 인덱스
 |                 |    +————————–> [41:29] L2 인덱스 (38:29 만 사용)
 |                 +——————————-> [47:42] L1 인덱스 (미사용)
 +————————————————-> [63] TTBR0/1

KVM을 사용할 때, 하이퍼바이저는 커널 페이지를 EL2에서 커널 VA로부터 고정된
오프셋(커널 VA의 상위 24비트를 0으로 셋팅한)에 맵핑합니다:

시작 크기 용도
———————————————————————–
0000004000000000 0000007fffffffff 256GB HYP 내에서 맵핑된 커널 객체

[Linux:Kernel] AArch64 리눅스 부팅(AArch64 Linux Booting)

이 문서의 저작권은 GPL 라이센스를 따릅니다(This document is released under the GPL license).

Documentation/arm64/booting.txt

AArch64 리눅스 부팅

===================

Author: Will Deacon <will.deacon@arm.com>
번역  : 양정석 <dasomoli@gmailREMOVETHIS.com>
Date  : 07 September 2012

이 문서는 Russell King의 ARM 부팅 문서에 기초하고 AArch64 리눅스 커널의
모든 공개 릴리즈와 연관됩니다.

AArch64 예외 모델은 몇 개의 예외 단계(EL0 – EL3)으로, 그 중 EL0와 EL1은
시큐어와 논-시큐어 구성을 가지는 것으로 구성되어 있습니다. EL2는
하이퍼바이저 단계이고 논-시큐어 모드에서만 존재합니다. EL3는 가장 높은
단계이고, 시큐어 모드에서만 존재합니다.

이 문서의 목적에 따라, 우리는 ‘부트 로더’ 용어를 간단히 리눅스 커널로
제어를 넘기기 전에 CPU(들) 상에서 실행되는 모든 소프트웨어로 정의하여
사용할 것입니다. 이것은 시큐어 모니터와 하이퍼바이저 코드를 포함할 것이고,
또는 최소 부팅 환경을 준비하기 위한 한 줌의 명령들이 될 수도 있습니다.

기본적으로, 부트 로더는 다음을 (최소한) 제공해야 합니다:

1. RAM을 셋업하고 초기화
2. 디바이스 트리를 셋업
3. 커널 이미지를 압축 해제
4. 커널 이미지를 호출
1. RAM을 셋업하고 초기화
————————

요구 사항: 필수

부트 로더는 커널이 시스템 상의 임시 데이터 저장 공간으로 사용할 모든
RAM을 찾아서 초기화할 것으로 여겨집니다. 이는 머신 의존적인 방법으로
수행됩니다. (자동으로 모든 RAM의 크기를 재고 위치시키는데 내부
알고리즘을 사용하거나, 머신 안의 RAM에 대한 지식을 사용하거나, 또는
부트 로더 설계자가 맞춰 보는 다른 방법을 사용할 수도 있습니다.)
2. 디바이스 트리를 셋업
———————–

요구 사항: 필수

디바이스 트리 조각 (dtb)는 8 바이트 경계로 커널 이미지의 시작으로부터
512 메가 바이트 내에, 그리고 2 바이트 경계에 걸치지 않도록 위치해야만
합니다. 이것은 커널이 초기 페이지 내이블 내의 하나의 섹션 맵핑을 사용해서
조각을 맵핑할 수 있도록 해줍니다.
3. 커널 이미지를 압축 해제
————————–

요구 사항: 선택

AArch64 커널은 현재 압축 해제기를 제공하지 않고, 그래서 압축된 Image 타겟
(예를 들면, Image.gz)이 사용된다면 부트 로더에 의한 압축 해제
(gzip, 기타 등)를 요구합니다. 이 요구 사항을 구현하지 않은 부트로더들을
위해서 압축되지 않은 Image 타겟이 현재 대신 이용 가능합니다.
4. 커널 이미지를 호출
———————

요구 사항: 필수

압축 해제된 커널 이미지는 다음과 같은 64바이트 헤더를 포함합니다:

  u32 code0;
/* 실행 가능 코드 */
  u32 code1; /* 실행 가능 코드 */
  u64 text_offset; /* 이미지 로딩 오프셋 */
  u64 res0 = 0; /* 여분으로 예약 */
  u64 res1 = 0; /* 여분으로 예약 */
  u64 res2 = 0; /* 여분으로 예약 */
  u64 res3 = 0; /* 여분으로 예약 */
  u64 res4 = 0; /* 여분으로 예약 */
  u32 magic = 0x644d5241; /* 매직 넘버, 리틀 엔디언, “ARM\x64” */
  u32 res5 = 0;       /* 여분으로 예약 */
헤더 설명:

– code0/code1 은 stext로의 뜀을 책임집니다.
– EFI를 통해 부팅할 때, code0/code1은 초기에 건너 뜁니다. res5는
  PE 헤더로의 offset이고, PE 헤더는 EFI 진입 포인트(efi_stub_entry)를
  가집니다. 그 코드 조각이 작업을 끝내면, 보통의 부팅 프로세스를 재개하기
  위해서 code0 로 점프합니다.
  
이미지는 시스템 RAM의 시작으로부터 지정된 오프셋(현재는 0x80000)에
위치하고, 거기서 호출되어야만 합니다. 시스템 RAM의 시작은 2MB로 정렬되어져
있어야 합니다.

커널로 점프하기 전에, 다음 조건을 만족해야만 합니다:

– 모든 DMA 가능 장치들을 중지시켜 메모리가 가짜 네트워크 패킷이나
  디스크 데이터로 인해 깨지지 않도록 하세요. 이것은 많은 디버깅 시간을
  절약시켜 줄 것입니다.
  
– 주요 CPU 일반-목적(general-purpose) 레지스터 셋팅
  x0 = 시스템 RAM 내의 디바이스 트리 조각(dtb)의 물리 주소
  x1 = 0 (차후 용도를 위해 예약)
  x2 = 0 (차후 용도를 위해 예약)
  x3 = 0 (차후 용도를 위해 예약)  
  
– CPU 모드
  모든 형태의 인터럽트는 PSTATE.DAIF(Debug, Serror, IRQ 그리고 FIQ)로
  마스킹되어져야 합니다.
  CPU는 EL2(가상화 확장에 접근하기 위해서 추천함) 또는 논-시큐어 EL1 에
  있어야 합니다.

– 캐시, MMU
  MMU는 반드시 꺼져야 합니다.
  명령 캐시는 켜지거나 꺼져 있을 수 있습니다.
  로딩된 커널 이미지에 해당하는 주소 범위는 PoC로 깨끗해야 합니다.
  시스템 캐시나 켜진 캐시와 연관된 다른 마스터들의 존재 안에서,
  이것은 보통, 셋/웨이 연산보다는 VA에 의한 캐시 관리를 필요로 합니다.
  VA 연산에 의한 구조화된 캐시 관리를 준수하는 시스템 캐시는 설정되어져야
  하고, 켜지게 될 것 입니다.
  VA 연산에 의한 구조화된 캐시 관리를 따르지 않는(권장하지 않음) 시스템
  캐시는 설정되고 꺼져야만 합니다.

– 구조화된 타이머
  CNTFRQ는 반드시 타이머 주기로 프로그램되어야 하고, CNTVOFF는 모든
  CPU들의 일관된 값으로 프로그램되어야 합니다. 만약 EL1에서 커널로
  진입한다면, CNTHCTL_EL2는 반드시 셋팅된 EL1PCTEN(비트 0)을 가져야 합니다.

– 연관성
  커널에 의해 부팅될 모든 CPU들은 커널로의 진입 상의 같은 연관 도메인의
  일부가 되어야 합니다. 이것은 각 CPU 상의 관리 연산의 수신을 켜는
  ‘구현에 따라 정의된’ 초기화를 요구할 것입니다.
  
– 시스템 레지스터
  커널이미지가 진입하는 그 예외 레벨에서 모든 쓰기 가능한 구조화된 시스템
  레지스터들은 ‘알려지지 않은’ 상태 내의 실행을 막기 위해서 더 높은 예외
  레벨에서 소프트웨어에 의해 초기화되어야만 합니다.

위에 쓰여진 CPU 모드, 캐시, MMU, 구조화된 타이머, 연관성과 시스템 레지스터들에
대한 요구사항은 모든 CPU에 적용됩니다. 모든 CPU는 같은 예외 레벨 안에서
커널로 진입해야 합니다.

부트로더는 각 CPU가 다음과 같은 관례로 커널로 진입할 것으로 생각합니다:

– 주 CPU는 커널 이미지의 첫 명령으로 직접 점프해야만 합니다. 이 CPU에 의해
  넘겨진 디바이스 트리 조각은 각 CPU 노드의 ‘enable-method’ 프로퍼티를
  포함해야만 합니다. 지원되는 enable-method 들은 아래에서 설명합니다.

  부트로더는 이들 디바이스 트리 프로퍼티를 생생하고 커널 진입보다 먼저
  조각 안에 그들을 끼워 넣을 것입니다.

– “spin-table” enable-method 의 CPU들은 그들의 cpu 노드 내에
  하나의 ‘cpu-release-addr’ 프로퍼티를 가져야 합니다. 이 프로퍼티는
  자연스럽게 정렬된 64비트의 0으로 초기화된 메모리 위치를 나타냅니다.

  이 CPU들은 예약된 영역 안에 포함되어야만 하는, 그들의 cpu-release-addr
  위치를 폴링하는 (디바이스 트리 안의 /memreserve/ 영역에 의해 커널로
  전달되는) 메모리의 예약된 영역 안의 커널 밖에서 돌아야 합니다.
  wfe 명령은 비지-루프(busy-loop)의 부하를 줄이기 위해서 추가될 것이고,
  sev는 주 CPU에 의해 일어날 것입니다. cpu-release-addr에 의해
  가리켜지는 위치를 읽는 것이 0이 아닌 값을 반환할 때, 그 CPU는 이 값으로
  점프해야 합니다. 그 값은 하나의 64비트 리틀 엔디언 값으로 쓰여질
  것이므로 CPU들은 읽은 값을 그리로 점프하기 전에 그들 원래의 엔디언으로
  변환해야 합니다.

– “psci” enable method의 CPU들은 커널의 밖(즉, memory 노드 안에 커널로
  기술된 메모리의 그 영역 밖, 또는 디바이스 트리 안의 /memreserve/ 영역에
  의해 커널로 기술된 메모리의 예약된 영역 안)에 남아 있어야 합니다.
  커널은 커널 내로 CPU들을 가져오기 위해서 ARM DEN 0022A
  (“Power State Coordination Interface System Software on ARM processors”)
  문서 안에 설명된 것처럼 CPU_ON 호출들을 일으킬 것입니다.
  
  디바이스 트리는 하나의 ‘psci’ 노드를
  Documentation/devicetree/bindings/arm/psci.txt 안에 설명된대로
  포함해야만 합니다.

– 두번째 CPU 일반-목적 레지스터 셋팅
  x0 = 0 (차후 용도를 위해 예약)
  x1 = 0 (차후 용도를 위해 예약)
  x2 = 0 (차후 용도를 위해 예약)
  x3 = 0 (차후 용도를 위해 예약)

향수의 Type? Eau de cologne

요즘 향수를 쓰는데, 향이 금방 사라진다는 느낌이 들어 안책임님께 여쭤보니, 향 지속시간에 따른 등급(?) 같은게 있는 모양이다. 그래서 찾아보았다.

퍼퓸(Perfume) : 향료를 15 ~ 30% 함유. 6시간 이상 지속
오드퍼퓸(Eau de perfume) : 향료 9 ~ 12% 함유, 5시간 정도
오드트왈렛(Eau de toilette) : 향료 6 ~ 8% 함유. 4시간 정도
오드코롱(Eau de cologne) : 향료 3 ~ 5% 함유. 오드콜로뉴라고도 읽는 모양인데 정확치 않다.

내 건 마지막에 Cologne 라고 쓰여있다.
출처: http://magazine.hankyung.com/jobnjoy/apps/news?popup=0&nid=05&c1=5005&nkey=2014052800056056305&mode=sub_view

* 남성과 여성?
일반적인 구어 영어에서 Perfume은 여성의 향수, Cologne는 남성의 약한 향수를 뜻하기도 하는 듯.

* 오 드 콜로뉴
원래의 오 드 콜로뉴는 ‘쾰른의 물’이라는 이름의 향수를 이름을 바꾼 것으로, 모조품에 대항하기 위해서 파리나 콜로뉴(Farina cologne)라는 상표명으로 바꾸었다. 이게 오 드 콜로뉴의 원조로 이어지고 있다나..
출처 :  http://terms.naver.com/entry.nhn?docId=1127928&cid=40942&categoryId=32161