C2k10-guenther

Данная статья 100 % копипаст с www.openbsd.ru

Перевод "[c2k10] Interview with Philip Guenther (guenther@) Part 9" (оригинал)

Мне очень интересно узнавать о разработчиках OpenBSD. Они приезжают из разных мест земного шара с разным образованием и опытом, и всё равно они собираются вместе для достижения одной цели. Кто эти люди? Что подтолкнуло их к использованию и разработке OpenBSD? Какое у них образование и где они работают? Вы будете удивлены, узнав ответы на некоторые из этих вопросов. Они удивили и меня, и Филип Гюнтер (guenther@) не был исключением.

Серия статей: 1 2 3 4 5 6 7 8 9 (продолжение следует)

На данный момент я посетил несколько хакофонов, и это мой третий большой хакофон после посещения c2k6 и с2k8. По сути дела, как я понял, на хакофонах есть несколько выразительных голосов которые узнаваемы и ожидаемы. На c2k10 был один [голос] который я не узнал и это был голос guenther@'а. Первым моим впечатлением, которое мне запомнилось, было то что guenther@ не был застенчивым в выражении своего мнения и делал это авторитетно, но при этом никогда не настаивал на нём [как на последней инстанции]. Он выбрал себе место за столом вместе с Марком Кеттенисом (kettenis@) и Дейлом Раном (drahn@), которые, надо заметить по меньшей мере не новички, а может даже он сидел с двумя великанами мира OpenBSD.

Я встречал многих разработчиков OpenBSD которые занимают высокие должности в компаниях [в которых они работают]. Диапазон их должностей варьируется от IT-управленцев до CTO и guenther@ является Главным архитектором в Sendmail Inc. Что приводит руководящие кадры, такие как guenther@, к хакерству в OpenBSD? Ну, кроме интересных задач и отрады [их решения], как само по себе разумеющееся, они знают что таким образом могут сохранить порох в пороховницах, так сказать.

В то время как многие просто использовали лаптопы, guenther@ хакерствовал на самой непонятной клавиатуре (Kinesis Advantage), какую я никогда и не видел. Вас может впечатлить использование очень эргономичной и эзотерической клавиатуры, её владелец ещё должен уметь классно программировать впридачу к такому монстру. Однако, когда вы слышите как guenther@ кодирует на ней вслепую, вам может показаться что он использует обычную клавиатуру. Это была определённо самая громкая клавиатура в комнате.

guenther@ начал использовать OpenBSD 12 лет назад когда работал сисадмином. После перехода в Sendmail Inc. в 2000 году, он стал использовать OpenBSD гораздо больше. OpenBSD стала его основной операционкой на работе и дома в течение некоторого времени. Он получил свой CVS акаунт в январе 2008 года и с тех самых пор работал над нитями (тредами), обработкой сигналов, libc, stdio, рамдиском и ядерными блокировками. После того как узнаёшь это, ты понимаешь что он сел за правильный стол с правильными людьми. В самом деле, стол рядом с ними был не менее оживлённым, а может и громче, за которым сидели beck@, art@, thib@, oga@ и blambert@ который юморил по ходу дела. По правде сказать эти два стола были источником в значительной степени источником шума и веселья на всю комнату.

Вот что guenther@ пишет про c2k10:

чистка инклудов

Это часть долгого проекта по зачистке наших заголовочных файлов, для того чтобы ускорить компиляцию, сократить зависимости, сократить утечку пространства имён, сократить кросс-платформенные противоречия, улучшить соответствие стандартам, и установить мир во всём мире. Сегодняшние этапы касались , который подключает ворох файлов в которых на самом деле нет нужды и которые содержат код который уже не используется. Удаляя последнее, [это] помогает нам сократить пространство на ядерном стеке, в дальнейшем можно будет использовать несколько меньше страниц, сберегая память и сокращая число страничных ошибок. Также подчистили в котором был старый compat код.

чистка названий rdomain/rtable

В 4.7 мы добавили системный вызов setrdomain() для установки маршрутного домена процесса. Мне показалось что будет полезно сделать ключевое слово для ps(1) которое сможет отобразить его, но побеседовав с Клаудио, Питером и Рейком, мы пришли к выводу что они [rdomain/rtable] были названы некорректно: В действительности по умолчанию [подразумевается] таблица маршрутизации, а не домен. Клаудио единственный кто документировал это, но вкратце [картина такова], маршрутные домены являются понятием второго уровня (l2) -- каждый интерфейс связан с маршрутным доменом и пакеты получаемые на этом интерфейсе обрабатываются в этом домене -- в то время как таблицы маршрутизации - это понятие третьего уровня (l3) -- каждый сокет связан со своей таблицей маршрутизации и пакеты посылаемые через этот сокет маршрутизируются согласно таблице маршрутизации, и каждая таблица маршрутизации находится "внутри" заданного маршрутного домена и может только маршрутизировать только на интерфейсах входящих в этот маршрутный домен. Таким образом, Клаудио провёл большую часть времени, ваяя здоровенный дифф, который исправит именование всех системных вызовов, опций сокетов, опций командной строки, переменных ядра, и прочее. Я потратил немного времени на инспектирование его диффа-в-процессе и предложением поработать побольше ;-) C этими изменениями, мне теперь надо обновить и вновь разослать мой дифф который добавляет поддержку rtable в 'ps' и 'fstat'.

прочая чистка

tedu@ и я удалили кучу старых опций COMPAT_* которые предоставляли поддержку бинарников от других ОС: BSDOS, HPUX, IBCS2 (Xenix!), M68K4K, OSF1, SUNOS, и ULTRIX. Они не использовались и не поддерживались долгое время и стали мешать внесению других изменений. Например COMPAT_HPUX был единственным камнем преткновения перед удалением структуры user, также некоторые другие делали моё хакерство над rthreads тяжелее. procfs вскоре тоже попадёт под раздачу...

rthreads: ядерные структуры

После чистки, я провёл оставшуюся часть недели, работая на большим диффом который меняет связи между структурами данных которые используются ядром для слежения за процессами, нитями, процесс-группами, и сессиями, чтобы rthreads могли правильно вести себя при использовании таких вызовов как fork(2), wait(2), и setpgrp(2). В основном [эта работа] включает в себя перенос данных из тредовых структур (struct proc) в процессные структуры (struct process), но код которые работает с этими связями немного сложен в некоторых областях, в частности очистка процессов и трейсинг (для обоих ktrace и ptrace). Брет и я пробовали ранее несколько раз в этом году разбить это изменение на несколько малых этапов, затрагивая часть связей на каждом этапе, но взаимоотношения только сильнее переплетались и делали нестабильным результат [этой] промежуточной работы. Сейчас это один большой 3000 строчный дифф который я вскоре передам Тео для снапшотов...

ld.so

Дейл и я немного поковырялись в ld.so, стараясь помочь друг другу не потеряться в запутанном клубке связных списков. У него было улучшение производительности для исполняемых файлов с многими зависимостями, у которых в свою очередь также много зависимостей, также я подчистил [ld.so] и сделал пару заглушек на будущее.

Было также много других исправлений и дискуссий, включая 25 летний дефект API DNS резолвера, которые [исправления] можно со всей очевидностью назвать непортируемыми, некоторые исправления в обёртке execve из libpthread, другая ошибка в блокировке списка ядерных процессов была добавлена сразу после 4.7, некоторые проверки устойчивости sysctl ABI, и чистка некоторых древних неиспользуемых участков кода в структурах plimit и pcred.

Филип

Как вы можете видеть guenther@ упорно работал в областях ядра, куда не каждый решится сунуться, не говоря о том что способности на это есть у единиц. После того как я встретил его, я рад что он настолько глубоко запустил свои руки во внутренности OpenBSD. Если вы ничего не знаете о его программистских способностях и опыте, встретившись с ним, то он может убедить вас в том что он является правильным человеком для того чтобы выполнить работу. Я также почувствовал, и это подтвердилось, это в его взаимодействии с Тео и другими людьми. Я встретил много новых и интересных людей в этом году на большом хакофоне и guenther@ был одним из тех людей которые оставляют положительное впечатление после встречи с ними. Спасибо Филип!

Марк Т. Уемура