올 추석에는 “코틀린 쿡북” 을 읽고 있습니다.

하도 여기저기서 올해 추석에는 집에만 있으라는 시그널이 많아서, 집에서 읽을 만한 책들을 고르다, 코틀린 쿡북이 회사에서 먼지가 쌓여가는게 보여서 잠시 데려와서 읽고 있습니다. 아직 초반부만 읽어보고 있는데, 나름 산을 올라가는 느낌으로 각각의 레시피 형태의 나름 익숙 한 패턴인 ( 문제 – 해법 – 설명 ) 형태로 기술된 짤막한 쿠키스타일의 단원들을 읽고 있습니다. 어찌보면, StackOverflow를 요약한 것과도 같은 느낌이긴 한데, 패턴 학회에서 여러 글들을 보아온 저로서는 패턴 쪽으로 마음이 기웁니다. 출판사가 출판사인지라… 저작권에 은근 O’reilly스러울 줄 알았는데, 전문에는 나름 오픈 마인드로 코드 내용등에 대한 코멘트 인용 등에 대해서 좀 더 용인하는 듯이 써있네요…. 그래도 조심해야하니, 일단 인용한다는 표식부터 남깁니다. “코틀린 쿡북, 켄 코우젠 지음, 김도남 옮김, 책만, ISBN 9791189909147”

일단 코틀린은 계속 얘기만 들어보고, 안드로이드 플랫폼 코드에서 슬쩍 구경만 해 본 정도라서 뭐 아는 것도 아니고, 모르는 것도 아닌 애매한 상태에서. JVM의 바이트코드를 내뿜어, 자바 실행 파일과 동일한 효과를 가진 실행 파일들을 내준다는 정도로만 이해하고 있었습니다. PLOP을 다니면서, 여러 언어들에 대해서 생각을 해보기도 하고 접해보기도 했는데, LLVM이후로 모든 인간 중심의 언어들이 무수히 자라나는 걸 보고 있기도 해서, 그냥 아무 언어나 나도 만들어 봐야 하나 싶기도 하지만, 과거의 경험 들과 검증된 것들이 차곡차곡 쌓여서 발전되고 있는 언어들을 보고 있으니, 또 막 그러면 안될 것 같기도 하고, 이래저래 마음이 싱숭생숭 해 집니다. 실제 벌어 먹고 살기 위한 업무가 돌아가는 것도 그렇고, 생태계라 불리는 것도 그렇고, 무엇 하나 자연이 그러하듯, 조금씩 조금씩 바뀌어 가면서 커지고 복잡해지고, 또 그러다가 다시 단순한 기반 아래로 다시 구축되고, 기존과 여전히 같은 개념들을 공유하고, 역사가 반복되는 듯한 느낌을 받고 그런 거죠.. 나이 들었다는 느낌을 이래저래 많이 받고 있습니다.

일단은 앞부분의 play.kotlinlang.org에서 살짝 맛보기를 보고. 그래도 뭔가 하는 사람인 것 처럼 보이기 위한, 컴파일러/REPL 및 개발환경 꾸미기부터 해보고 있습니다. 책에서도 그렇지만, 하도 여기저기서 채택하고 퍼져나가고 있다고 해서, 이것저것 툴도 많은 것 같은데, 익숙한 AndroidStudio나, IntelliJ, 그냥 쉘 정도 세가지 다해보면 되겠네요.

곧 PLOP2020입니다.

올해는 원래 콜로라도에서 개최될 예정이었으나, 그 코로나19에 의해, 전세계 모든 컨퍼런스 세미나들이 그렇듯, PLOP도 Virtual Conference로 온라인상으로 진행됩니다. 주로 챗을 열고, 한사람이 강의를 하거나, 서로간에 온라인으로 이야기를 주고 받으면서 진행될 것 같습니다. 일전에 8월달에 이미 AsianPLOP이 그런 형태로 이미 진행되었다고 합니다. 나름 한편으로는 PLOP의 주요 활동인 셰퍼딩에 이제는 일반화가 되어버린 화상챗이 대중적으로 사용되어 도리어 지나온 과거보다는 피드백이 좀더 좋아졌다고 해야할까 싶지만.. 영어가 원어가 아닌 입장으로서는 그냥 메일로 주고받는게 더 효과적일지도 모르겠습니다. 실제 본 PLOP에서의 Writer’s Workshop에서도 말하는게 참 힘들었기도 했고요. 아무튼 올해는 올해대로 기대는 됩니다. 단지, 한가지… 밤시간이라는 것만 뺀다면 말이죠 –;; 시간표를 잘 짜두어야겠습니다. 10월은 9월까지의 과실들을 여기저기서 수확하는 시기라서 시간이 조금만 틀어져도 큰 손실을 받는 해니까 말이죠. 올해는 PLOP하고 겹쳤던 SOSCON이라도 봐볼까 싶기도 합니다. 나름. 회사에서 주최하는 것이기도 하고 오픈소스 관련 행사이기도 하고…

새 빌드 머신 성능.. 최고는 아니어도 예전의 편안함은 가져오는 8700

Update 09/14 : Linux Native로 옮기고. 한번더
SSD : 72876 01:32:15 R Incremental 이정도면 밥먹고 오면 될정도.
HDD: 80827 03:01:20 S Incremental

i7-8700 에 Windows host – VirtualBox – 6thread 설정, SSD로 빌드시 2시간 정도에서 이전대비 반타작 빌드가 가능하네요. 100% 72876/72876 02:01:23. 속 시원하지 않아도, 이전의 숨막힘은 없어져서 좋습니다. 10 thread로 할당 늘려보고. 리눅스 native로 바꾸어서 해보면 더 나아지겠죠. 이전 PC방출로 고심되네요. 팔릴려나..

근데 요즘 계속 구글이나 페북이나, thinkStation P620 광고가 계속 눈에 들어옴… 얘들아 너네들 그러는거 아냐… 그러라고 광고개인화 허용해준거 아니다.. T.T

Android R official release r3 build

Update:2020-09-12
오늘 sync해보니 뭔가 바뀌어 있음.. manifest snapshot은 같은데.. 뭘까. –; 잠정적인 결론은… S master branch에서 빌드한 out가지고, R로 브랜치만 바꾼 뒤에 그냥 빌드 해서 인가봄.. -,.-;; clean 빌드 가동!

-> Clean build 결과,, Fail …했다가 성공.. 도합 11:01:31 –; 오늘 8700 32GB짜리 중고로 업어왔으니 이제 바꿔서 테스트합니다. 구형 리눅스 머신은 이제 작별해야겠네요..

다 와서. system.img 생성 실패 –;; 어..음..
lunch menu 2번 aosp_arm64-eng 에서 사용되는 BoardConfig는 아래 두개임을 확인함.
1. /build/target/product/aosp_arm64.mk
2. /build/target/board/generic_arm64/BoardConfig.mk
3. /build/make/target/board/BoardConfigGsiCommon.mk
4. /build/make/target/board/BoardConfigMainlineCommon.mk
5. /out/soong/Android-aosp_arm64.mk
3번 파일에서 SYSTEM_RESERVED를 늘리면, 전체이미지에서 여분으로 빼는 공간이 빠져서 마이너스 효과.
1번 파일이 메인 configuration
2번 파일에 수정을 가하면, mk파일 200여개를 새로 읽음.
5번파일이 합쳐진 Android.mk

BOARD_SYSTEMIMAGE_PARTITION_SIZE를 지정하면, 아래 오류…
build/make/core/config.mk:903: error: Should not define BOARD_SYSTEMIMAGE_PARTITION_SIZE and BOARD_SYSTEMIMAGE_PARTITION_RESERVED_SIZE together.

./make/tools/releasetools/test_verity_utils.py:175: DEFAULT_PARTITION_SIZE = 4096 * 1024
./make/target/board/BoardConfigEmuCommon.mk:37: BOARD_SUPER_PARTITION_SIZE := 3229614080

아래파일이 로그와 마찬가지로 기록됨
out/target/product/generic_arm64/obj/PACKAGING/systemimage_intermediates/system_image_info.txt
out/target/product/generic_arm64/misc_info.txt


아무래도 크기 계산은 그냥 맞아떨어지는 것 같은데 selinux때매 부가적으로 추정 로그 찍어주느것 같고.

범인은 아래 같은데, 파일 찾기가 더럽게 어려움. –;

오늘이 AOSP R버전 Release, Master Branch도 안정적

Update(9/10): 8550U Virtualbox 4 core설정으로 38637/69452 4:00:13 fail

Update: Master Branch와 싸움중.. 27881/30200 에서 4코어 프로세서에서 기본 m으로 들어가니 6~8정도로 쓰레드 도는것 같은데.. 1:49:05 만에 30 G메모리로 뻑났음.. –; 아래와 비슷한 상황.. 그래서 그냥 -j4옵션으로 실행중. 남은거 1775컴파일하고 있는데, 죽지는 않겠지.. 근데 시간은 더 오래걸리는 느낌 –; 1775/1775 에 51:39 –; SSD가 이럴진대… HDD로.. 옮겨서 또 걸어봅니다.
HDD빌드는 28910/29518 2:35:02 JDK 11.0.4+0-6508549 에서 크래시… 노트북에서 실행한 VirtualBox도 아예 크래시 –;; VirtualBox다시걸고, HDD쪽은 636/636 14:00 빌드완료가 되네요.
SSD 27881+1775 = 29656에 1:49:05+51:39 = 2:40:44
HDD 28910+636 = 29546에 2:35:02+14:00 = 2:59:02
대부분은 CPU Bound같습니다.. SSD에서 이득보는 부분이 그다지 크지는 않아보이네요
대략 전체 빌드에 10만~13만 정도 작업이 있었으니, 저 시간의 3배인 8~9시간 걸리는게 맞네요. 하아..

Old: R은 나올꺼고. S master를 보고 있는데, 여전히 Fail이네요. –; 활발해보입니다.

AOSP빌드해보기, 벌써 S, 빌드된다~! 근데 R태깅은 Still망. android-r-beta-3

9/7일자, Build Fail –;; 6:19:09 초 만에 –;

9/6일자 Master branch 빌드 성공, 8/30에서의 diff build인데. 4:!6:45 –;; 뭔가 특단의 조치가 필요함.

어제부(2020/8/30)로 MASTER branch받아보니 빌드 성공했습니다~!! 만세~~!!. R도 곧 Official Release이니, 이것저것 확인해서 다 고친 모양입니다. 그래도 언제 깨질지 모르기에. manifest snapshot 올려둡니다. Daily로 빌드 확인하는걸 만들어보던가 해야겠네요. 그나저나 빌드 시간이 9:44:29 –;; 예전엔 안이랬던것 같은데.. A10-5800K에 32GB는 동일한데.. HDD로 바꾼게 영향이 클지 모르겠네요. 개발용 PC 바꿔야겠.. T.T. 게임을 끊어야 T.T

휴가기간에 이것저것 점검하면서, 전에 해봤던 pure AOSP빌드를 시도해봅니다. 전에 중고로 업어온 3만원짜리 서버를 Recasing한, I7 3770의 성능도 볼겸 해서요. 원래 Main Game PC가 아직도 1055t에 8GB, 750ti 로 버티고 있었는데, CPU사양은 이걸 훌쩍 뛰어넘네요.. 신품 사기 더 싫어집니다 –; 요즘 PC들은 CPU보다도 GPU쪽에 투자를 많이 한다고(.. 게임말고, DeepLearning용으로,, 혹은 코인?) 들어서 중고시장쪽도 봤는데.. 1060이 많이 거래되는것 같더군요.. 예전엔 롤 돌릴때 수준으로 아무거나 쓰면 거의 되었는데, 배그 할때는 1060정도가 거의 최소인것처럼 얘기가 되나봅니다.. 아직도 Skyrim에 DragonAge Inqusition도 못깨서.. PC업그레이드 한참 뒤의 일이네요… 위쳐 3정도가 해보고 싶은건데 그마저도 아마 본격 게임머신을 ‘중고’로 사서 할 확률이 높네요. 최근은 GTA5를 이제사 할 수 있게 되어서, 요즘 공짜 많이 풀죠… 750TI가 조금 아쉽다 이긴한데.. 그보다도, 유로트럭2를 메인게임으로 두고 있기에 –; 유로트럭2에서 사장님 소리 듣기 전까지는 다른게임도 못할것 같습니다..

잡설은 그만하고, 일단 source.android.com에 가서 가이드대로 코드를 받아옵니다. 예전에 비해서, 가이드 글이 상당히 친절해지고 내용도 풍부해진걸 알 수 있었습니다. 다만 검색과, 메뉴 Navigation은 여전히.. 이건 뭔가 하는 느낌이 들긴 합니다. 그냥 구글페이지 검색창에서 찾아서 들어오는게 더 낫습니다 –;;; 용량은 다받으면 200GB에 육박해서. HDD는 단디 각오하고 준비해둬야하겠고요. 최근에 3TB HDD오랜 만에 ‘중고’로 또 사서, 이부분은 넉넉해졌습니다. 당근마켓 사랑해요~
용량도 많아서 mirror로 받아서, mirror에서 repo 땡겨오는 만행도 저질러 봅니다. mirror서버는 따로 돌리고 싶지만, 어차피 이 PC아니면 개발할때 쓰지도 않을 것 같고(미안하다, A10-5800K머신아…) 원래 리눅스 메인머신이 한대 있는데, 3770한테 바로 밀렸습니다. 요즘 에어컨 많이 틀어서 전기요금도 살짝 걱정되어서 PC두대 켜기도 그렇고, 무엇보다, 다락 전기라인에 6구 멀티탭이 이미 3개인상태라 불날까봐서 여러대 작동을 못 시키겠습니다 그 중 하나가 에어컨을 쓰고 있어서요 –; 가정용 MAX가 30A라죠.. 에어컨이 1700W~600W정도라, PC한대두대 300W정도씩 더하면, 까딱하면 차단기 떨어질 수 있겠습니다.

source.android.com에서 가이드대로 repo sync가 무사하게 완료되면, 역시나 가이드대로, . build/envsetup.sh 와 lunch 명령어로 빌드할 타겟 보드를 잡아주고, make를 쓰던간, 환경설정시에 들어 있는 ‘m’, ‘mm’, ‘mmm’을 활용하면 됩니다. m명령어로 root부터 전체 빌드를 할 수 있도록 되어 있어 AOSP에서는 편리한데요. 기타 여러 스크립트를 추가로 작성해서 하는 방법도 있겠습니다. 근데 실행해보니 에러가 나오네요. 전에도 봤던것 같은데. dependency가 들어 있는 코드와, 해당하는 모듈이 포함되어 있지 않아서 발생하는 것으로 보입니다. 검색을 해봐도 딱히 뭐는 안 나아오고, 그나마 찾은건 ALLOW_MISSING_DEPENDENCY=true로 설정하라는 것 정도 밖에는 못찾겠네요. 근데 해봐도 동일합니다. 예전 기억에 이것으로 해결 경우 친절하게 가이드가 나왔던것 같은데, 너무 빌드 초기에 실패로 나오고 있어서 살짝 당황스럽습니다.

AOSP가 이렇게 관리가 안될까 라는 의문과 함께..(안되는게 맞긴 합니다만) HDD용량도 넉넉하니.. 할 수 있는 BuildTarget을 모두 실험해 봅니다.. 휴가때 하기 좋네요…아닌가.?.. 1~10, 38, 41번 하고 관뒀습니다. 이 정도면 그냥은 안될 것 같습니다. 여기서 해볼 수 있는건, 이제 이전의 뭔가 Stable버전을 찾아서 돌아가는게 되겠지요.. Q버전으로 과감하게 돌아가봅니다. 그럴려고 .repo/manifests에서 가서 확인해보는데, 몇가지 조금더 해볼만한게 보이네요.

AOSP의 manifest파일들이 보입니다. 현재는 아무런 branch정의 없이 가져와서 코드 상태는 origin/master를 보고 있습니다.

이전 기억으로는 origin말고 aosp가 따로 있었던것 같은데 말이죠.. 기분 탓인가 봅니다. origin은 remote 이름이라서, branch이름은 아닐테니까요.

현재로서는 달리고 있는 최신 버전일터인, android-r-beta-3으로 가봅니다.

mirror를 다시 설정하는건 시간이 오래걸려서 안되겠고, 그냥 googlesource.com에서 바로 받아서 빌드를 거니 진행이 되네요. 이제 빌드 완료되는것 보고 코드레벨로 비교를 해보는 수고를 하면 master branch가 왜 빌드가 깨졌는지 알 수 있겠지만… 일단 보류합니다. 빌드가 또 깨지네요.. T.T. 후닥 찾아보니, 질문은 있고 답은 아직 없네요 –;
https://stackoverflow.com/questions/63355052/error-for-building-android-11-source-code
중국에서 열심히 삽질한게 보이긴하는데… 흐음.. 다 읽긴 귀찮고, 메세지 일치하는것만 빼옵니다. 일부 Conflict이 나오는데, 알아서 잘 고치면 됩니다.. 일단 삭제쪽인게 많아서, git rm으로 지워주고, 일부 수정은 패치의 내용대로 따라가도록 고치면 될것 같네요.
https://www.xiezeyang.com/2020/07/25/Build/Android11-beta2-%E7%BC%96%E8%AF%91%E6%8A%A5%E9%94%99%E9%97%AE%E9%A2%98%E5%A4%84%E7%90%86/

/libcore/apex
git fetch https://android.googlesource.com/platform/libcore refs/changes/97/1312197/1 && git cherry-pick FETCH_HEAD
conflict: git rm으로 해결

/libcore
git fetch https://android.googlesource.com/platform/libcore refs/changes/98/1333998/12 && git cherry-pick FETCH_HEAD
conflict: current-api.txt는 이전 내용 유지, 다른것은 최근 내용으로 교체

/external/linux-kselftest
git fetch https://android.googlesource.com/platform/external/linux-kselftest refs/changes/87/1252987/1 && git cherry-pick FETCH_HEAD

/external/seccomp-tests
git fetch https://android.googlesource.com/platform/external/seccomp-tests refs/changes/67/1253167/1 && git cherry-pick FETCH_HEAD

/art/build/sdk -> libcore쪽 패치 추가
git fetch https://android.googlesource.com/platform/libcore refs/changes/29/1321929/3 && git cherry-pick FETCH_HEAD

/external/gptfdisk
git fetch https://android.googlesource.com/platform/external/gptfdisk refs/changes/90/1319790/5 && git cherry-pick FETCH_HEAD

/external/grpc-grpc-java/auth -> prebuilts/tools
git fetch https://android.googlesource.com/platform/prebuilts/tools refs/changes/67/1344767/5 && git cherry-pick FETCH_HEAD
conflict: 날짜 최신것으로 교체
git fetch https://android.googlesource.com/platform/prebuilts/tools refs/changes/68/1344768/6 && git cherry-pick FETCH_HEAD

/external/grpc-grpc-java/protobuf
git fetch https://android.googlesource.com/platform/prebuilts/tools refs/changes/76/1320776/8 && git cherry-pick FETCH_HEAD
conflict : 날짜 최신것으로 교체
git fetch https://android.googlesource.com/platform/prebuilts/tools refs/changes/20/1323020/3 && git cherry-pick FETCH_HEAD

/libcore/mmodules/core_platform_api -> libcore패치 추가
git fetch https://android.googlesource.com/platform/libcore refs/changes/32/1325832/4 && git cherry-pick FETCH_HEAD

/frameworks/base -> libcore에 패치 추가
git fetch https://android.googlesource.com/platform/libcore refs/changes/70/1268170/2 && git cherry-pick FETCH_HEAD

/cts -> libcore에 패치 추가
git fetch https://android.googlesource.com/platform/libcore refs/changes/62/1268162/2 && git cherry-pick FETCH_HEAD

/libcore
git fetch https://android.googlesource.com/platform/libcore refs/changes/24/1321924/3 && git cherry-pick FETCH_HEAD
git fetch https://android.googlesource.com/platform/libcore refs/changes/66/1235266/7 && git cherry-pick FETCH_HEAD
git fetch https://android.googlesource.com/platform/libcore refs/changes/99/1258499/1 && git cherry-pick FETCH_HEAD
git fetch https://android.googlesource.com/platform/libcore refs/changes/34/1297334/3 && git cherry-pick FETCH_HEAD
conflict: target삭제후 shared_lib에 추가된것을 취함.
git fetch https://android.googlesource.com/platform/libcore refs/changes/30/1250330/10 && git cherry-pick FETCH_HEAD
위것보다 먼저 넣는게 좋겠음.
Conflict : 최신파일 내용으로 그냥 다 교체해버림.
git fetch https://android.googlesource.com/platform/libcore refs/changes/72/1254472/5 && git cherry-pick FETCH_HEAD
git fetch https://android.googlesource.com/platform/libcore refs/changes/14/1278614/2 && git cherry-pick FETCH_HEAD

/external/chromium-libpac
git fetch https://android.googlesource.com/platform/external/chromium-libpac refs/changes/23/1283723/1 && git cherry-pick FETCH_HEAD

여기까지 하면, 일단 빌드 시작들어갑니다만, build fail뜨네요 –; 일단 MultiThread Build를 믿고 몇번 더 걸어봅니다. 특정 모듈에서만 나오고 있을 거라서 나머지는 진행될꺼거든요. 안되네요 -.-;

제 빌드머신은 Ubuntu 20.04LTS입니다. 아마도.. library 의존성이 달라져서 이겠지요.. 보통 Backward compatibility목적으로 재설치나 링크 변경 해야했던 적이 있었으니까요.. 아래정도 찾아봅니다.
https://back2basics.io/2020/05/creating-a-android-aosp-build-machine-on-ubuntu-20-04/
https://kibua20.tistory.com/39

역시 추가설치가 필요한가봅니다.
sudo apt install libncurses5

이후 또 –; 다시 패치들을 뒤적입니다.. 왠마한건 다 있네요 –;;. FRC나 되어서 제대로 된게 나오려는지.. Official Release가 9월 8일이군요.
https://www.androidauthority.com/android-11-release-date-1085250/

/external/e2fsprogs
git fetch https://android.googlesource.com/platform/external/e2fsprogs refs/changes/16/1250416/2 && git cherry-pick FETCH_HEAD

또 빌드 에러

/libcore 에 넣을꺼 많네요
git fetch https://android.googlesource.com/platform/libcore refs/changes/42/1348842/1 && git cherry-pick FETCH_HEAD
Conflict: Latest로 넣으면 되는데, 중간에 많이 빠진것 같네요.. 에효

git fetch https://android.googlesource.com/platform/libcore refs/changes/62/1260462/1 && git cherry-pick FETCH_HEAD

git fetch https://android.googlesource.com/platform/libcore refs/changes/46/1244646/7 && git cherry-pick FETCH_HEAD

git fetch https://android.googlesource.com/platform/libcore refs/changes/14/1280514/1 && git cherry-pick FETCH_HEAD

이제 족보가 없는, 빌드에러가 나옵니다. –;; 일단 자야겠네요.

다시금 직접 받은 master branch로 돌아오고(-b master), export ALLOW_MISSING_DEPENDENCIES=true로 놓고하니, skia_deps를 넘어가고 빌드가 되네요 -.-;;; 여태의 삽질은 뭐란말인가…

휴가의 내리막.

올 여름은 코로나 때문에 굳이 멀리는 가지 않았습니다. 이전에도 멀리 간적은 없었지만, 아이들이 크면서 조금 더 멀리 오래 캠핑같은걸 갈 수 있을 줄 알았는데, 귀찮음에 더해서 여러 상황이 도와주지는 않는 것 같네요. 덕분에 집도 좀 정리하고, 근방 지역 문화재 탐방정도에서 휴가의 전반기를 보냈습니다. 후반기에 접어드니, 코로나 상황은 더 안 좋아지네요. 백신이 나오면 과연 종결될 것인지 살짝 의구심도 듭니다. 연초에 뉴스를 처음 접했을 때는 신종 플루급으로 해마다 고생할거리가 늘겠구나 했는데, 백신 개발이 생각보다 더디고, 전파는 생각보다 빨랐던 듯 합니다. 무엇보다. 인구가 많은 나라들에서부터 확산세가 심하다보니, 세계적인 경고가 나오니 우리나라도 어쩔 수 없이, 조심하는 측면이 강한 것 같습니다. 제 짧은 해외 경험상 우리나라가 가장 걱정도 많고, 은근 신경 쓰면서 조심하는게 많다고 생각했는데, 이번에 더욱 느끼게 된 것 같습니다.

휴가 기간에 작업실공간을 좀더 분리해서 놀이용 테이블과 작업용 테이블 두개의 공간으로 나누어 봤습니다. 전에는 한 키보드 마우스로 여러대의 컴퓨터, 여러대의 모니터를 공유 혹은 번갈아 쓰자 였는데.. 하다보면 계속 게임만 하게 되는걸 다시금x100번 깨달아서, 아예 리눅스 머신들과, 윈도우 머신(게임머신)으로 분리를 했습니다. 업무용비슷하게 윈도우 머신이 필요할 때는 노트북이 있으니, 굳이 무거운 PC들과 큰 모니터를 보고 있을 필요는 없어 보이고요. 작업할때는 작은 모니터가 집중이 더 잘되는 것 같습니다. 물론 회사에서 쓰고 있는 48인치 UHD TV의 경우에는 회사 일 하기에는 참 좋습니다. 이것저것 띄우고 할게 많아서요. 폰트 크기도 적당하게 나오고. 회사 가고 싶네요… 아주 잠깐, 설겆이 할때는 –;

휴가 셋째날에는 근처의 오산 오색시장엘 들렀습니다. 와이프가 자주보는 놀라운토요일의 도레미마켓에 나왔던 음식도 먹어볼겸, 시장 구경도 할겸, 겸사겸사 갔는데, 점심 즈음에 갔더니 아직, 가게들이 완전히 문을 열진 않았고, 막 시작하려는 분산함이 보였고, 지나다니는 손님들도 한산하다 할정도였습니다. 다섯가지 색깔을 시장 통로를 다 둘러보고 슬슬 물건을 사기 시작할때 즈음부터 사람들이 몰려들다는 느낌이 들었네요. 야시장도 시작하는 날로 들었는데, 낮에 생각보다는 많이 돌아다녀서 저녁은 깔끔하게 포기했습니다. 대신 시장에서 이것저것 사서 저녁거리로 챙길 생각이었는데, 사고 나보니, 산거라고는 꽈배기, 도너츠, 고로케, 수박, 인절미 정도네요… 네.. 그거로 저녁을 때웠습니다. –; 수박은 다음날 해체 했는데.. 3천원 치고는 크고 맛있어서, 재래시장 갈 맛이 나는구나 생각이 들더군요.

책을 읽었습니다. 5G Network Slicing for 5G and Beyond Networks

국내에 번역서나, 한글서적으로 나와있을지도 모르지만. 일단 구한건 외국원서입니다. Network Slicing for 5G and Beyond Networks. S.M. Ahsan Kazmi, Latif U.Khan, Nguyen H.Tran, Choong Seon Hong, Springer, 2019.
저자중 한분이 홍충선 교수님이시네요. 저자는 경희대 세 분과 러시아 이노폴리스 대학, 시드니 대학으로 구성되어 있습니다. 하드커버이긴한데, 한 손으로 들고 읽기에도 부담 없는 무게의 책입니다. 가격은 요새 원서들이 다 그런지 모르겠지만, 10만원을 넘어서네요. 대학 교재로 쓰던 것도 인터넷 서점에서는 그 가격인 걸 보면, 대학에 싸게 공급하는건지 모르겠네요.. 아니면 요새 정말 원서 값이 그 정도인지.. 그렇다면 대학생들 정말 공부하기 힘들겠네요. 등록금도 비쌀텐데…

그냥 스윽 훑어본 느낌으로는… 논문이네요 –;; 요샌 스펙문서도 거의 이 정도 규모급이긴 하던데, 후딱 읽어보고 같은 부서분께 소감과 함께. 숙제를 넘겨야겠습니다. ^^; 요새 네트웍쪽은 뭔가 새로운 축약 용어들이 난무해서, 그냥 받아들이면 편한데, 따지고 들면 머리가 아파서, 상대하시는 분에 따라서 적절히 넘겨서 혹은 쉬운 용어로 대체해서 설명할 줄 알아야 할 것 같습니다. 그래서 이글에는 책에 나오는 용어 전체이름만 정리해 보도록 하겠습니다. 1/3 정도는 이미 일반인들에게도 익숙한 단어들로 보이는데, 나머지의 반은 기술쪽에 있는 사람도 쉽게 감 못잡을 용어들로 보이네요.

MIMO: Multiple-input and multiple-output
OFDMA : Orthogonal Frequency division Multiplexing Access
METIS : Mobile and wireless communications Enablers for Twenty-twenty(2020) Information Society
URLLC: Ultra-Reliable Low Latency Communications
eMBB : enhanced Mobile BroadBand
mMTC: massive Machine Type Communication
MBB: Mobile BroadBand
HetNets: Heterogeneous Networks : small cells under macro cell (https://www.3gpp.org/technologies/keywords-acronyms/1576-hetnet
D2D : Device to Device, “D2D pair can directly communicate without routing its traffic through the central base station”, p.4
LTE-U : LTE-unlicensed, “Licensed assisted access has been standardized by 3GPP where LTE-U is enabled for downlink communication while the uplink communication and control signaling is performed on the licensed band.”, p.5
SBSs: (low power) Small-cell Base Stations vs traditional Macro cell, aka femto cell, pico cells
MBS : Macro-cell Base Station, Macro Cell and SBS is linked with Fiber backhaul links
LBT: Listen Before Talk
NOMA: Non-Orthogonal Multiple Access, OMA : Orthogonal Multiple Access
WNV : Wireless Network Virtualization
InPs: Infrastructure Providers
MVNO: Mobile Virtual Network Operations
5G usecases : eMBB, URLLC, mMTC, Three anchor.
NFV: Network Function Virtualization
SDR : Software Defined Radio
SDN: Software Defined Networking

Mobile Network 및 5G 개요에 해당하는 Chapter 1 이 지나면(Paper 하나인듯)
Chapter 2 Network Slicing: The concept이 본격 시작됩니다.

여러 응용이라고 표현이 자주 나오는데, 거의 모든 네트워크 시장의 마켓별 분류정도가 됩니다. IOT, 센서네트워크, 통상의 컨슈머 셀룰러, 게이밍, 재난망 등등… 모두 다 몰아넣었네요. 핵심은 NFV가 될것 같습니다. NFV관련해서 거의 바이블처럼 생각되는 페이퍼가 있는데, 여기저기 인용을 하는 간접 페이퍼, Security관련한 페이퍼는 PLoP에 거의 전문으로 하시는 분이 있어서 많이 읽어봤네요. 근간이 되는 Paper도 읽어봐야할 것 같습니다.

MANO : Management And Orchestration
NGMN: Next Generation Mobile Network
Tenant : “Tenant denotes the users that can access the shared resources with specific privileges and access rights”, p.15

2.2 Network Slicing Principles
공통된 물리 네트워크 위의 여러 논리 네트워크들을 생성해서, 여러 마켓 어플리케이션을 서비스 하는 것이라고 되어 있네요. 원칙은 3가지로

Slice Isolation : 성능과 보안을 여러 Tenants들에게 독립적으로 제공해야 한다입니다. fair sharing of the resources라고는 하는데, fair가 참 애매해보입니다.

Elasticity : 자원할당을 자유자재로 변경할 수 있는것을 얘기하네요. 효율성이 주요 키워드겠습니다.

End-to-End Customization : 이것도 효율성인 것 같은데. 앞서서는 자원의 재할당이었다면, 이번에는 utilization에 초점이 있는 듯 합니다. 어렵네요. 미래얘기인 듯 써 놓기도 했습니다.

SDN : Floodlight, Onix, NOX, OpenFlow, kandoo, Huperflow, ONOS 등 뭔가 많네요.
NFV : “uses commodity hardware to run software virtualization techniques for implementation of network functions”, p.18 결국 경제 논리인 듯 합니다.
Cloud-Computing도 얘기가 나옵니다. 기존의 xAAS를 사용자 관점의 분류로 이야기하고 있습니다. 맞는 것 같기도 하네요.
IAAS: Infrastructure as a Service, Network Architects
PAAS: Platform as a Service, Application Developers
SAAS: Software as a Service, End users

Cloud Deployment Models로 다섯가지로 분류하고 있습니다.
Private, Public, Community, Hybrid, Virtual PRivate

Requirements for Cloud Computing in 5G로 패턴에서는 Forces로 SE에서 항상 얘기 되던 것들을 나열합니다. 왠지 친숙하네요

Reliability, Sustainability, Scalability, Fault Tolerance, Security and Privacy

그리고 Edge Computing 얘기가 나옵니다.
“edge computing comes into the picture which leverages pushing of the storage and computing resources to the edge of the network”, p.22
동의어 혹은 분류로 cloudlets, fog computing, mobile edge computing, 각각 Satyanarayanan et al., CISCO, ETSI 에서 밀고 있다고 하네요. 또 각 데이터 센터, 라우터/게이트웨이, 모바일 베이스 스테이션을 위한 개념들이라고 합니다.

Chapter 3 Resource Management for Network Slicing

점차 모바일 기술 용어들이 나타나기 시작합니다.

RAN: Radio Access Network
RAT : Radio Access Technology
CN : Core Network
QoS : Quality of Service
BS : Base Station
sub 6G, over 6G hz 얘기도 나오고요.
5G NR : 5G New Radio
BS에서의 Content Caching얘기도 나오네요. Backhaul 부담 덜어주는 목적으로

3.1.2 Network Slicing 책 제목의 주요 키워드가 드디어 등장합니다.

Application의 예로서 Argumented reality applications : ultra-realiable and low latency, VOD : high throughput, 그리고 Network As A Service용어가 등장합니다.
관련인으로서 다음 문장이 확 와 닿네요
“They do not consider specific algorithmic approaches for slice creation ,slice allocation, slice interactions, admission control, etc.”, p27 … 아몰랑이 생각납니다. –;;
2015, 2016년에 걸쳐서, SKT, Ericsson, NTT DoCoMo, Huawei, Deutsche Telekom, ZTE, Chnia Mobile 들이 뭔가 될거라고 보여줬다고 합니다…. 하아… 2020년인데….
SDN, Virtualiation, NVF는 발전이 많았는데, RAN Slicing은 아직 미비하다고 하네요. 아마 이 책에서 얘기할 듯 합니다.
3.2 RAN Resources : 중요한 세가지 종류로, Radio Resource, Cache Resources, MEC Resource를 꼽고 있습니다.

Radio Resource: 는 주로 실제 Radio Sepectrum을 어떻게 할것인가에 대한 이야기를 하고 있습니다.

mmWave : Milimeter wave
MINLP: mixed-integer nonlinear programming, 리소스 할당의 최적화 이야기에서 나오는 얘기네요. 두가지 주요 알고리즘중 하나이고, 다른 하나는 QoS based radio resource management라고 합니다.
two-tier HetNet에서의 Resource Allocation에서의 문제가 mixed-integer resource allocation problem이란게 있다고 합니다. 이걸 duality-based혹은 matching theory로 해결한다고 합니다. 현재는.

알고리즘에서 고려하는 중요한 요소로 power가 얘기되고 있네요.

Caching으로 넘어가서, cache enabled C-RAN, cache enabled macro cellular networks, cache enabled D2D networks, cache enabled HetNets라고 네가지로 분류하여 설명하고 있습니다. 그리고 Machine learning에서 많이 듣건, Global Optimal Solution얘기하고, Decentralized algorithm, Centralized Algorithm 얘기가 적혀 있네요… NP-complete까지… near-optimal로 Dynamic Programming에,
SNM : Short Noise model 등등.. 알고리즘 용어 대잔치로 보입니다. Cache라는 주제로 다른 페이퍼 한뭉치는 나올 것 같네요.. 에휴.. 많다… Yang et al. 저자를 찾아봐야할듯 합니다.

Edge Computing Servers에서는 아까의 용어들 잔치와, offloading이라는 단어가 눈에 띄입니다.

3.3 Use Case들이 등작합니다. 각각에 대해서 수학적인 모델수식이 등장하기 시작하네요. 빨리 넘겨야겠습니다. 첫번째는 “Virtual Reality” 이네요. 계산식은 제법 단순한, Size, 즉 데이터 총량의 추정을 합니다. 이걸로 Learning알고리즘 돌리려나보네요.. 많이 보던 수식 패턴이 보입니다.

ADMM: Alternating Direction Method of Multipliers, 일반적인건지 저자가 제시하는 건지 모르겠는데. 주요 솔루션의 접근 기법이라고 합니다. 목적은 Task Offloading을 결정하기 위한것이라고 하네요.
PPP: Poisson Point Process, PPP가 이런 뜻으로도 되는군요 –;
암튼 그래프 제시와 함께 성능은 기존에 비해서 좋다고 합니다. 전형적인 페이퍼의 결론이되겠습니다. 다른 Use Case가 더 나올 줄 알았는데. 아니군요…. 하아… Reference는 43개나 되네요.. 고생 좀 했겠습니다.

Chapter 4 Network Slicing: Radio Resource Allocation

챕터 3이 Network Slicing이었는데. 이번엔 뭔가 부제가 더 붙었네요.

WNV: Wireless Network Virtualization, “These resources are then isolated to a number of virtual resources(slices)” , p.43, 가상화리소스가 거의 Slice와 동일개념으로 쓰이는 느낌입니다. “main goal is to assign slices to different mobile virtual network operators(MVNOs) such that the network utility is maximized”, p.43 제법 경제적인 논리로 설득력 있는 문장입니다. 동의합니다. 돈벌어야죠, 최대한 많이.

Radio Resource Allocation with Single InP : InP에서의 MVNO사업이 주요 골자이겠습니다. 망 대여하고 돈 버는 것.

InPs: Infrastructure Providers
RB : Resource Block
SLA: Service Level Aggrements
VR : Virtual Resource, 또 다른 VR입니다.
여기서는 수학 모델링에서, Bandwidth와 Power를 주요 계산요소로 따지고 있네요. 해결 알고리즘으로는 Matching Theory를 쓰고 있습니다.

아마 이론에서 나오는 용어들과 그 순서대로 문제를 풀어가고 있는것 같은데.
Matching Game: Preference Profile 이라는 개념이 있는 듯 합니다.
알고리즘 설명후 시뮬레이션 파트에서는 그림으로 Base Station에서 처리할 VNO user들을 점으로 표현한 걸 보니. 감이 어느정도 옵니다. 일단 골라서 서비스하면, 빼는식으로 계속 가다가 마지막에 자르기…

Radio Resource Allocation with Multi-InP : MNO+MVNO에서 여러 유저들을 할당하는 문제 같습니다. Base Station은 하나이고, Network Slice가 갖는 속성이 다를것으로 가정하여, 이게 본게임이 되겠네요. 거기에 MVNO들도 여럿이 될수도 있다고 하니, 난장판이겠네요. Fig 4.5는 Fig 1.5와 같은건데. 여기서 의미가 명확해지네요.

two-sided matching games을 쓰면 된다고 합니다. low-level game, high-level game으로 구분해서 단계적으로 차등으로 처리하나 보네요. 그래서 나오는게, Hierarchical Matching(HM) Game Algorithm이라고 합니다.
Stage 1: Low-Level Matching – Service Selection
Stage 2: High-Level Matching – Resource Purchasing
결과가 할당된 그룹이 나온다고 하네요.
단점은 Stage1이 고정되지 않으면 Stage2에도 영향을 주는 점이라고 합니다. 다음 논문주제가 되겠군요.
여기서의 Slice는 RAN Slice, Bandwidth 분할 할당 이야기이네요. 네 그랬었죠. Radio Resource Allocation

Chapter 5 Network Slicing: Radio Resource Allocation Using Non-orthogonal Multiple Access
네.. 챕터 제목이 점점 길어집니다 –;;

SIC: Successive Interference Cancellation
MBS: Macro Base Station

Fig 5.1 이 나오는데, Frequency-Time domain관련 Resource Block이 등장합니다. Slice간의 clustering 얘기가 나올 듯 합니다.

Matching Game for User clustering(NOMA clustering)

Matching Game with Externalities for User Clustering

Gale-Shapley style algorithm 등등 많이도 나오네요. 요건 적용안되서, blocking pair라는 개념이 쓰인다고 합니다.

Arithmetic-Geometric Mean Approximation
SCA: Succesive Convex Approxmiation, 아.. 알고리즘시간에 들었던 것 같은데…
JUCRAN: Joint User Clustering and Resource Allocation in NOMA. 아. 뭔가 억지스럽다…
KKT: Karush-Kuhn-Tucker 조건을 만족한다고합니다.. Centralized SCA-Based Power Assignment with AGM Appromixation이…

이 다음은 JUCRA 2 3으로 이어지는 Simulation결과로 끝날것 같네요.

Chapter 6 Network Slicing: Cache and Backhaul Resource Allocation

끝나지 않는군요. Network Slicing이란건…
“This work mainly dealt with the network virtualization targeting the uplink of a cellular network” p.91 라고 합니다. 핵심 그림은 Fig 6.1

풀어나가는 중에 나오는 알고리즘들, Hungarian Algorith, Distributed Algorithm(JSPA-HSA) HSA가 Hungarian-based Slice Allocation. JSPA는 Joint Slice and Power Allocation
MSA: Matching based Slice Allocation algorithm –;
BS: Bandwidth Slicing, 약어 힘드네요..

JP-ADMM: Jacobi-proximal alternating direction method of multipliers가 Decentralized 라고 합니다. PBCD보다 좋다고 합니다.. Proximal Block Coordinate Descent 흠.. general multi-convex 문제를 푸는데 쓰인다고 하네요.

Chapter 7 Network Slicing: Dynamic Isolation Provisioning and Energy Efficiency

이제 에너지가 등장했습니다. 통일은 없는걸까요? –;

NLS: Non-cooperative Leasing Game
Lyapunov Online Algorithm을 이용한다고 합니다.
CSI: Channel State Information
QSI: Queue State information
근데 수식은 많이 보던 Cost functoin형태이네요

Stackelberg Game and Stackelberg Equilibrium

Chapter 8 Concluding Remarks 마지막입니다. 오예.

오픈 이슈
1.Dynamic Slice allocation : 이 책에서 안 다룸. 실제 시스템과는 거리가 있음. –;;
2.Mobility Aware Network slicing: 다른 Station으로 도망간다면, Inter-InP

세줄 요약
1. RAN Slicing에 대하여 다루었음.
2. 여러 가지 알고리즘으로 RAN의 주요 요소와 속성들을 고려하여 문제들을 풀었음
3. 실험환경 내에서의 결과 한정으로 할것 많음.

소감
UE를 주로 다루는 제 입장에서는 MNO(InP)가 MVNO를 고려해서 Network Slice를 만들어 내고 있다라고 밖에는 안 느껴지네요… 돈때문에.
책 번역본은 절대 안 나올 듯 합니다. 논문집이라…

오늘은 GKI 빌드를 시도해봅니다.

GKI는 안드로이드에서 Treble의 거진 마지막 단계로, 플랫폼뿐만 아니라, 커널도 단일된 하나의 커널을 쓰겠다는 정책입니다. 현재 안드로이드 플랫폼은 제조사마다 여전히 차이가 있지만, 개발단계에서는 GSI를 사용하여, 업데이트가 벤더에 의존하지 않고 독립적으로 될 수 있도록 테스트등을 진행하도록 하고 있습니다. 물론… 잘 되고 있는지는 의문입니다만, 결국 구글의 것은 구글의 것대로 하나로 관리하겠다는 의도로 보입니다. 여태까지는 제법 잘 굴러가고 있지만, 부담이 없는건 아니겠지요.

아무튼 GSI AOSP던 GKI던 모두 근본 오픈소스 프로젝트에 기반하여, 코드는 공개되어 있고, 모두 확인하고, 빌드하고,, 기회가 있다면, 단말이나, 가삼머신에서 실행해 볼수 있겠죠.. 그래서,, 해봅니다. 오늘은 GKI입니다.

커널 소스는 안드로이드 사이트에 구글치고는 꽤 상세한 설명과 함께, 코드 접근 방법등이 설명되어 있습니다.
https://source.android.com/devices/architecture/kernel

코드는 아래에서 접근이 가능하겠고요.
https://android.googlesource.com/kernel/common/

현재 최신 버전의 안드로이드에 밀고 있는 커널은 5.4커널입니다. 이번에 Ubuntu 20.04 LTS도 5.4커널이라고 하지요. 문서화 된 내용들을 보면, 상당히 깊이가 있고, 뭔가 안드로이드 특화된 기능들이 많이 기술 되어 있는데요. 현재 안드로이드 커널과, 리눅스 커널은 약간 밀당 관계라, 리눅스 mainline upstream으로 들어가는것도 있고, 여전히 못들어가고 Android mainline에서만 들어가고 있는 것들이 있습니다. 나름 기술적인 의도로 대부분 판단하지만, 이게 또 정치판하고 같아서, 패치하나로 설전이 오가는 메일쓰레드 구경하는 것도 재미가 제법 쏠쏠합니다.

아무튼 코드를 받아서 빌드를 시도해봅니다. 머신에 여타 빌드 환경같은것 설정한게 없으니, 무작정 돌려봅니다.
make gki_defconfig 돌리면 처음 맞이하는게
scripts/Makefile.host:9: recipe for target ‘scripts/kconfig/lexer.lex.c’ failed

네 학교에서 배운 기억이 납니다. Lexer가 없네요.. 오픈소스에서 컴파일 하면 들어가야 하는, 그러니까. GCC, G++같은 컴파일러를 만들고자 할때 쓰는. 구문해석기. BISON, FLEX를 깔아줍니다. 원래는 LEX/YACC지만.. 오픈소스 Free Software니까…

빌드 2차시도
error: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel
네. 바이너리 관련해서 또 처리를 못하네요.. 앞에 두개만 깔고 다시 시도해봅니다. 근데 libelf-dev는 없다고 나오네요.. Ubuntu 18.04인데.. 그냥 하나만 깔고 시도해봅니다.

scripts/extract-cert.c:21:10: fatal error: openssl/bio.h: 그런 파일이나 디렉터리가 없습니다
#include
^~~~~~~
compilation terminated.
scripts/Makefile.host:107: recipe for target ‘scripts/extract-cert’ failed
make[1]: *** [scripts/extract-cert] Error 1
make[1]: *** 끝나지 않은 작업을 기다리고 있습니다….

자 이제 생각없이 안깔아본 세번째를 깝니다. 세번째도 없네요.. 흠.. 첫번째 제안 패키지만으로는 아직 뭔가 부족한가봅니다.
구글신게 도움을 요청합니다.
https://github.com/TinkerBoard/debian_kernel/issues/26
libssl-dev 라고 하는군요

뭔가 HDRINST라는게 무식하게 많이 찍히고, HDRTEST가 많이 찍히고, 평소 보던 CC/AR 이 간간히 보입니다. 헤더 다루는게 예전보다 더 많아진 모양입니다. Precompiled Header하고 하기에는, 같은게 너무 많이 반복적으로 나오는게, 좀 비효율인 처럼 보이기도 하네요..

빌드가 잘 진행되는데,, 생각보다 많이 느려서, top으로 잠시 살펴봅니다… 별 생각 없이 ntfs로 포맷한 SSD에다 받아놓고 빌드를 했는데, mount.ntfs가 CPU 50%이상을 먹고 있네요 –;; 화딱지 나서, 받아놨던걸 살짝 옮겨놓고, ext4로 다시 밀어버리고 빌드를 합니다. 이제야, 70%대에서 놀던 CPU들이 90%까지 바득바득 일을 하기 시작하네요.. 역시 순정(?)이 좋습니다.

이번엔 Kivy입니다.(kivy는 좀 나중에보고, Termux먼저 봅니다)

지난번에 업무상 필요한 툴들을 모아둘 필요가 있어, 여러 Bash툴들을 Python으로 컨버팅하면서, PySimpleGUI로 약간의 GUI를 곁들여 만들어 본게 있습니다. 이번엔 안드로이드 단말에서 뭔가 간단하지만 약간은 난이도가 있는 쉘 기능을 활용해야하는 경우가 발생해서, Kivy로 갑니다. 구글검색으로 국내 블로그등에서도 별로 다루지는 않았던 듯 합니다. 2013년도 쯤부터 몇몇 글이 보이고, 2018~2019년도 들어오면서 좀더 주목받고 유튜브 외국 강좌도 보이고, Udemy에도 강좌가 보이고 하는데, 굳이 초 다중 MultiPlatform을 타겟하는게 없어서인지, 각각의 OS마다 이미 충분하게 개발환경이 편하게 되어 있어서인지 모르겠는데, 일단 해봅니다. 목적은 어디까지나 안드로이드 앱으로 쉘 기능을 간단하고 편하게 잘 써보기 입니다. 권한 막히는 것은 뭐 어쩔수 없겠지요…

일단 Kivy가 그렇게 확 뜨지 않는건, 일단 영어고.. PySimpleGUI처럼 Cookbook스타일의 예제 중심의 따라하기가 조금 모자란면도 있어 보입니다.

10분뒤…

원래 생각했던건 약간의 GUI가 있으면 좋겠다였고, 쉘기능이 잘 되면 좋겠다였어서, 기준이 되는 앱은 Termux였습니다… 근데 소스가 공개되어 있네요 –;; 바로 방향전환 합니다…

https://github.com/termux/termux-app