Deweloperzy NetBSD-7.0: Antti Kantee

Antti Kantee jest długoletnim deweloperem NetBSD, ostatnio zaangażowanym w rozwój technologii rump kernel, futurystycznej koncepcji oprogramowania.


 

 

Antti Kantee is a NetBSD old timer & developer, lately working on his rump kernel technology, a futuristic software design.


 

1. For the readers who don’t know you yet, can you shortly introduce yourself?

I’m Antti, and some in the NetBSD community refer to me with my NetBSD login „pooka” (yes, from the old DigDug game … long story). I’ve been a NetBSD developer for close to half of my life now, and have touched more or less everything from assembly bootstrap routines to pkgsrc and htdocs. I’m also a former member of the core team, and back in the days when the NetBSD source repository was hosted at the Helsinki of University of Technology I had some adventures with the project admins (even longer story/stories).

2. Why did you choose to run NetBSD? How long have you been using it? What are your ports (hardware platforms)?

Back in high school in the latter half of the 90’s I was experimenting with a bunch of different operating systems. That was back in the days when you had to download bootfloppies and actually install an OS instead of just spinning up a VM, so it was a non-trivial (but worthwhile) experiment. Out of Slackware Linux, FreeBSD, NetBSD and OpenBSD, NetBSD worked the best for me, so I stuck with it. Off the top of my head, I’ve installed and run NetBSD on real hardware on x86, alpha, evbarm, mac68k, shark, sparc, sparc64, pmax and sgimips. Of course, at some point over the years I grew old and lazy and these days I prefer a single laptop and a bunch of virtual machines over the metric ton of hardware I used to have to plug cables into.

3. For those readers that still haven’t joined the NetBSD community, why should they try NetBSD?

NetBSD’s biggest strength is its incredible attention to solid engineering. At the same time, that attention is also NetBSD’s biggest weakness. The type of people who are attracted to NetBSD tend to be people who, to paraphrase the intro of a math book I used to study, have a strong interest to learn technology for its own sake. If you are a person who really wants to learn how to do things properly, there is no substitute for NetBSD. For the rest, my view of NetBSD is that of a solid foundation upon which you can build the bells and whistles that normal people would be interested in.

4. In your professional environment, do you work with NetBSD?

Yes. Let me give a non-conventional example of how I’ve used NetBSD in a professional context.

Last year I was contracted to write a driver for the Intel 3160/726x wireless chips, a driver which became iwm(4) and according to my understanding has now been ported to all BSDs. There was no documentation for the chips except 40,000 lines of Linux driver code, so it was essentially the typical matter of guessing what magic bits the device wants by means of quasi-bruteforce.

The customer’s target system was OpenBSD, so naturally the deliverable was an OpenBSD driver. What I ended up doing was writing a NetBSD driver, and porting the finished driver to OpenBSD. It took about an afternoon to port the finished driver to OpenBSD, so I lost some time there. However, by doing all of the device side iteration with a NetBSD driver, I was able to take advantage of the ability to run the unmodified kernel driver as a rump kernel in userspace. That ability meant I could test each magic bit guess in a second, regardless of if the previous iteration crashed, burned or otherwise jumped to hyperspace. When the driver was finished, it simply worked in kernel mode. Over the course of the thousands of iterations I did to uncover the magic bits, I’d estimate that the ability to do the development in userspace saved me at least a month of time. One month, give or take, minus an afternoon is still one month. So, I saved a lot of time by writing an OpenBSD driver initially as a NetBSD driver and then porting it over — you can use NetBSD in a professional context also solely to make your life easier.

5. How did you become a NetBSD developer? What do you think is required in order to join the NetBSD project as a developer?

I was sending patches to various packages and eventually Hubert Feyrer asked me if I’d rather commit the patches directly myself.

Apart from a solid interest in tech, patience is required. The developer application process is rather lengthy when compared to the „click-click-done” approach commonly seen in the fast-paced world of contemporary open source software.

6. Can you tell us about some NetBSD-related areas you work on?

These days my work is „limited” to rump kernels. I say „limited” in quotation marks because in reality that work takes me to almost every corner of the NetBSD source tree from general kernel infrastructure to kernel drivers and to userland utilities to the build system.

7. What’s your NetBSD workflow?

The tools I use are pretty standard: vi, make, gdb, nm/objdump/readelf, bc, and a lot of xterms. I like to test code very frequently while I’m developing it, because it helps me mentally keep track of what’s working and what still needs investigating — research shows that humans can keep 7 items in short-term memory, so I guess that’s a good guideline for how many untested things your code under development should maximally contain. Once you test some pieces, you can merge them in your mind into a larger unit to keep below the magic 7: unify and conquer!

If I’m working on a larger, mostly self-contained feature, I guess I do something like development driven testing, where I start building the tests at the same time as the code. I usually try to get to a point where I have a self-contained test program so that I don’t have to waste time with the testing — you can probably easily see that if it’s kernel development, I do it in a rump kernel whenever even remotely possible. A fully self-contained test isn’t a hard rule, though; for example, if I’m testing network stack modifications, I usually run the peers in two separate xterms (or screen windows or whatever), since it’s just easier to control the test, observe debug output and attach debuggers that way. Finally, when everything is working, I evaluate if for that specific case it’s appropriate to port my test program to the NetBSD test framework and add it to the automated tests

8. Do you have an idea of the time you spend working on the NetBSD project?

All of it. 😉

9. Please tell us about the strongest points and features of the 7.0 release.

An updated release with support for the latest and greatest external interfaces in terms of hardware and software interfaces is always great to have. Many people put an incredible amount of hours into making NetBSD usable in the real world, so it’s nice to see that work „graduate” with a release.

In terms of technology, I’m most excited about Lua scripting in the kernel. Granted, it’s a developer-oriented feature, but with the right amount of attention it could have a dramatic impact on what the NetBSD kernel is able to deliver to everyday users. Let’s face it: C programming is hard and fiddly, and there’s really no reason to write everything in C.

10. Please tell us about some improvements for the NetBSD project that are worth picking up for newcomers?

For new contributors, especially in the base system and kernel, the most useful habit to pick up is adding a test for everything. We have a test framework from which the tests are automatically run multiple times a day. If you care about a feature and want to see it continue to work as expected, there’s no substitute for adding an automated test.

11. As a conclusion, can you tell us how you forecast NetBSD future?

This might get a bit long, since I have quite a lot of ideas on the subject. 😉

In my opinion, the future of NetBSD looks extremely bright. The world is on the brink of a paradigm shift where the relevance of traditional general purpose operating systems will be greatly diminished, and the OS will be replaced with more agile, case-specific software stacks running on specialized devices and the cloud. One good example of this phenomenon is the explosive interest in unikernels over the past 6 months.

You might wonder if the statements of NetBSD’s bright future and general purpose operating systems being phased out are contradictory. They are not. To construct new-style software stacks, you still need driver-type components for things to work. Those components have to come from somewhere, and the only currently existing large-scale production quality source for them is NetBSD. Projects such as Genode, Mirage, Hurd and Qubes are either already using, or a developer is looking into using, NetBSD kernel components to construct new style software stacks. Other traditional OSs are slowly waking up to the systems paradigm shift, e.g. Linux with the libOS project. However, „when the future hits the fan” very soon now, NetBSD will be the only system with years of experience in the game. It is highly likely that in the future NetBSD users will see a lot of „familiar-looking” software in other systems.

If you want a more in-depth discussion of the above forecast, check out my article „The Rise and Fall of the Operating System”, published in this month’s USENIX ;login: magazine. You can download a free pdf here:

http://www.fixup.fi/misc/usenix-login-2015/login_oct15_02_kantee.pdf

But what about the future of NetBSD the OS? Is it doomed? Don’t worry, NetBSD the OS is not going anywhere for a long time. There is a lot of synergy between NetBSD the OS and NetBSD the codebase (obviously 😉 ). For example, recently someone was interested in making the Rust language and its standard library work on the Rumprun unikernel (which is based on NetBSD the codebase). Since there was no existing NetBSD support, that was written as part of the project. The result is that people who use NetBSD the OS can benefit from the work done by folks who would not necessarily otherwise be interested in NetBSD the OS. So, simply put, everyone using NetBSD wins, regardless of if they use it in „traditional mode” or „new style”. That synergy is why the future of NetBSD looks very bright.


1. Czy mógłbyś powiedzieć parę słów o sobie dla czytelników, którzy jeszcze Cię nie znają?

Jestem Antti, a niektórzy w społeczności NetBSD zwracają się do mnie moim loginem w NetBSD – „pooka” (tak, to wywodzi się ze starej gry DigDug … jest to długa historia). Prawie połowę mojego życia spędziłem jako deweloper NetBSD i zetknąłem się mniej więcej ze wszystkim – od startowania systemu w kodzie assemblerowym po pkgsrc i htdocs [szablon strony www – przyp. tłum.]. Byłem też kiedyś członkiem zarzątu NetBSD [ang. core – przyp. tłum.], a kiedyś, w czasach gdy kod źródłowy NetBSD był hostowany na Politechnice Helsińskiej, miałem styczność z zespołem administratorów projektu (a to nawet dłuższa historia).

2. Dlaczego wybrałeś NetBSD? Jak długo korzystasz z tego systemu? Z którymi portami (platformami sprzętowymi) masz do czynienia?

W szkole średniej, w drugiej połowie lat 90., eksperymentowałem z wieloma różnymi systemami operacyjnymi. Było to w czasach, gdy trzeba było ściągać obrazy dyskietek i instalować system operacyjny na sprzęcie fizycznym, zamiast po prostu uruchamiać maszyny wirtualne, więc nie był to wcale taki prosty (ale warty zachodu) eksperyment. Spośród Slackware Linux, FreeBSD, NetBSD i OpenBSD, NetBSD działał mi najlepiej, więc pozostałem z nim. Z czego co pamiętam na gorąco to zainstalowałem i uruchomiłem NetBSD na [następujących portach: – przyp. tłum.]: x86, alpha, evbarm, mac68k, shark, sparc, sparc64, pmax i sgimips. Oczywiście, w pewnym momencie, po upływie lat, zestarzałem się i rozleniwiłem i obecnie od ton sprzętu, do którego kiedyś musiałem podłączać kable wolę pojedynczy laptop i kilka maszyn wirtualnych.

3. Dlaczego czytelnicy, którzy jeszcze nie przyłączyli się do społeczności NetBSD powinni tego spróbować?

Najmocniejszym punktem NetBSD jest przywiązanie do solidnej pracy inżynierskiej. Jednocześnie jednak jest to najsłabszym punktem NetBSD. Ludzie, których pociąga NetBSD często są ludźmi, którzy – że sparafrazuję wstęp do książki do matematyki, z której kiedyś się uczyłem – bardzo chętnie uczą się technologii ze względu na nią samą. Jeśli jest się osobą, która naprawdę chce się nauczyć właściwego wykonywania zadań, nie ma nic lepszego niż NetBSD. Jeśli chodzi o resztę, podchodzę do NetBSD jak do solidnego fundamentu, na którym można zbudować bajery, którymi zwykli ludzie by się interesowali.

4. Czy w swoim środowisku zawodowym masz do czynienia z NetBSD?

Tak. Podam może niekonwencjonalny przykład tego, w jaki sposób korzystam z NetBSD w środowisku zawodowym.

W zeszłym roku zlecono mi napisanie drivera do bezprzewodowej karty sieciowej Intel 3160/726x, sterownika, który został nazwany iwm(4) i z tego co zrozumiałem został teraz przeportowany do wszystkich systemów BSD. Nie było żadnej dokumentacji do tych chipsetów z wyjątkiem 40 000 linijek kodu źródłowego w kernelu Linuksa, więc zasadniczo była to typowa zgadywanka, poprzez sprawdzanie trochę na siłę których magicznych bitów oczekuje to urządzenie.

Systemem docelowym klienta było OpenBSD, więc oczywiście zleconym produktem był sterownik OpenBSD. Skończyło się to pisaniem przeze mnie sterownika NetBSD i portowaniem skończonego drivera do OpenBSD. Przenoszenie skończonego kodu do OpenBSD zajęło mniej więcej jedno popołudnie, więc zmarnowałem przy tym nieco czasu. Jednakże poprzez wykonanie całej pracy nad urządzeniem w NetBSD, byłem w stanie wykorzystać możliwość, by uruchamiać niezmodyfikowany kod kernelowy w postaci rump kernela w przestrzeni użytkownika. Możliwość ta oznaczała, że mogłem przetestować każdy magiczny bit w sekundę, bez względu na efekt jego uprzedniej iteracji: czy to był zwykły błąd, spalenie urządzenia czy wyskok w kosmos. Kiedy driver był skończony, od razu po prostu działał w przestrzeni kernela. Podczas tysięcy iteracji, które wykonałem, by odkryć te magiczne bity, szacuję, że możliwość wykonania dewelopmentu w przestrzeni użytkownika pozwoliła mi zaoszczędzić co najmniej miesiąc. Plus minus miesiąc nawet bez jednego popołudnia jest nadal miesiącem. Tak więc zaoszczędziłem dużo czasu poprzez wcześniejsze napisanie sterownika OpenBSD jako sterownika NetBSD i potem przeportowanie go na docelową platformę – a więc można korzystać z NetBSD w środowisku zawodowym również tylko po to, by ułatwić „sobie” życie.

5. W jaki sposób zostałeś deweloperem NetBSD? Co – Twoim zdaniem – jest potrzebne by zostać członkiem projektu w roli dewelopera?

Wysyłałem łatki do różnych paczek i w końcu Hubert Feyrer zapytał mnie, czy może już sam nie wolałbym ich commitować osobiście.

Poza zdecydowanymi zainteresowaniami technicznymi, potrzebna jest cierpliwość. Proces aplikacji dewelopera jest dość długi w porównaniu z podejściem „kliknąć-kliknąć-gotowe”, które jest powszechnie spotykane w szybkim i dynamicznym świecie współczesnego oprogramowania Open Source.

6. Czy mógłbyś powiedzieć parę słów o obszarach Twojego zaangażowania w NetBSD?

Obecnie moja praca ogranicza się do rump kerneli. Mówię „ogranicza się” w cudzysłowie, bo w rzeczywistości moja praca dotyka prawie każdy kąt w drzewie NetBSD, od infrastruktury kernela poprzez sterowniki i narzędzia użytkowe do systemu budowania.

7. Jaka jest Twoja organizacja pracy z NetBSD?

Narzędzia, z których korzystam są dość standardowe: vi, make, gdb, nm/objdump/readelf, bc i wiele instancji xterm. Lubię często testować kod podczas gdy nad nim pracuję, bo to pomaga mi mentalnie nadążać za tym, co się dzieje i co wciąż wymaga zbadania – badania naukowe wskazują, że człowiek jest w stanie przechować w pamięci krótkotrwałej 7 elementów, więc sądzę, że to jest dobra wskazówka dotycząca tego, ile nieprzetestowanych elementów powinien maksymalnie zawierać kod, nad którym się pracuje. Gdy testuje się pewne elementy, można je w swoim umyśle połączyć w większe jednostki, żeby ich liczba była poniżej tej magicznej 7-tki: ujednolicaj i zwyciężaj!

Jeśli pracuję nad większą, zazwyczaj samowystarczalną funkcjonalnością, sądzę, że wykonuję coś w rodzaju Test-driven development [technika rozwoju oprogramowania polegająca na aktywnym pisaniu testów funkcjonalnych – przyp. tłum. ], w którym zaczynam równocześnie pisać testy i kod funkcjonalności. Zazwyczaj próbuję dojść do momentu, gdy mam samowystarczalny program testowy, żebym nie musiał marnować czasu na testowanie – możesz zapewne łatwo spostrzec, że jeśli jest to rozwój kernela, wykonuję go w rump kernelu, gdziekolwiek to jest choć trochę możliwe. Pełny, samowystarczalny test nie jest jednak sztywną regułą; jeśli na przykład testuję zmiany w stosie sieciowym, zazwyczaj uruchamiam dwie instancje w dwóch osobnych xtermach (albo sesjach screen czy jakkolwiek inaczej), jako że po prostu łatwiej jest kontrolować ten test, obserwować wynik debugowania i w ten sposób podpinać się debugerami. W końcu, gdy wszystko już działa, oceniam, czy w tym konkretnym przypadku należy przeportować moją pracę do frameworku testów NetBSD, dodając ją do testów automatycznych.

8. Ile czasu zajmuje Ci praca w projekcie NetBSD?

Cały mój czas. 😉

9. Proszę przybliż nam najmocniejsze punkty i cechy charakterystyczne najbliższego wydania NetBSD-7.0.

Zaktualizowane wydanie ze wsparciem dla najnowszych i najlepszych interfejsów, zarówno sprzętowych jak i programowych jest zawsze świetną rzeczą. Wiele osób wkłada niesamowitą ilość czasu w to, żeby z NetBSD dało się korzystać w rzeczywistym świecie, więc miło widzieć przy tym wydaniu, że ta praca przynosi efekty.

Jeśli chodzi o technologię, najbardziej jestem podekscytowany skryptowaniem kernela w jezyku Lua. Po prawdzie, jest to cecha zorientowana na dewelopera, ale jeśli poświęci się jej odpowiednio dużo uwagi, to może mieć to ogromny wpływ na to, czego kernel NetBSD może dostarczyć zwykłym użytkownikom. Spójrzmy prawdzie w oczy: programowanie C jest trudne i skomplikowane, ale naprawdę nie ma powodu, by wszystko pisac w C.

10. Proszę przybliż nam również obszary systemu NetBSD, które uznajesz za wartościowe do ulepszenia dla nowych deweloperów?

Jeśli chodzi o nowych deweloperów, zwłaszcza zainteresowanych systemem bazowym i w kernelem, to najlepszym zwyczajem, jaki mogą sobie przyswoić jest dodanie testów do wszystkiego. Mamy framework testów, w ramach którego testy są automatycznie uruchamiane wiele razy dziennie. Jeśli uważa się jakąś cechę za istotną i chce się, żeby dalej działała zgodnie z naszymi oczekiwaniami, nie ma nic lepszego niż dodanie testu automatycznego.

11. W ramach podsumowania, jaką kreślisz przyszłość dla NetBSD?

To może być trochę przydługie, jako że mam całkiem sporo pomysłów w tej kwestii. 😉

Moim zdaniem, przyszłość NetBSD wygląda na wyjątkowo świetlaną. Świat stoi u progu zmiany paradygmatu oprogramowania, gdzie znacznie zmniejszy się znaczenie tradycyjnych systemów operacyjnych służących ogólnemu celowi, a system operacyjny zostanie zastąpiony sprawniejszymi,  dedykowanymi do danych celów, zbudowanymi ze stosów oprogramowania, działającymi na wyspecjalizowanych urządzeniach i w chmurze. Dobrym przykładem tego zjawiska jest ogromne zainteresowanie unikernelami w ciągu ostatnich 6 miesięcy.

Można się zastanawiać, czy stwierdzenia dotyczące świetlanej przyszłości NetBSD i stopniowego wycofywania się systemów operacyjnych służących ogólnemu celowi są sprzeczne. Otóż nie są. Do zbudowania stosu oprogramowania w nowym stylu nadal będą potrzebne komponenty podobne do sterowników, żeby to wszystko działało. Komponenty te muszą skądś się brać, a jedynym obecnie istniejącym dobrym ich źródłem na dużą skalę i w jakości produkcyjnej jest NetBSD. W projektach takich jak Genode, Mirage, Hurd czy Qubes albo już się z niego korzysta, albo deweloperzy rozważają korzystanie z kernelowych komponentów NetBSD, żeby skorzystać z nowego stylu budowy stosu oprogramowania. Inne tradycyjne systemy operacyjne pomału się przygotowują do adaptacji nowego postępowania – np. Linux z projektem libOS. Jednakże, gdy wkrótce przyszłość postawi nas w trudnej sytuacji, NetBSD będzie jedynym systemem, który ma w tej grze już lata doświadczeń za sobą. Jest to niemal pewne, że użytkownicy NetBSD zobaczą w przyszłości znajomo wyglądające oprogramowanie w innych produktach.

Nieco bardziej pogłębione omówienie powyższej prognozy zostało zawarte w moim artykule „Wzlot i upadek systemu operacyjnego” (ang. „The Rise and Fall of the Operating System„), opublikowanego w bieżącym numerze czasopisma USENIX ;login: magazine. Tutaj można ściągnąć darmowy plik PDF:

http://www.fixup.fi/misc/usenix-login-2015/login_oct15_02_kantee.pdf

Ale co z przyszłością NetBSD w roli systemu operacyjnego? Czy jest już ona z góry przesądzona? Nie martwcie się, NetBSD nie zniknie jeszcze długo. Mamy wiele synergii między NetBSD w roli systemu operacyjnego oraz NetBSD w roli zbioru gotowego kodu źródłowego (oczywiście 😉 ). Na przykład, niedawno ktoś się zainteresował sprawieniem, by język Rust i jego biblioteka standardowa działały jako unikernel rumprun (który jest oparty na kodzie źródłowym NetBSD). Jako że nie istniało wsparcie dla Rusta w NetBSD, zostało ono dopisane jako część projektu. Skutek jest taki, że ludzie, którzy korzystają z systemu operacyjnego NetBSD mogą korzystać z pracy wykonanej przez ludzi, którzy w przeciwnym razie niekoniecznie zainteresowaliby się systemem operacyjnym NetBSD. Tak więc, mówiąc prościej, każdy kto korzysta z NetBSD wygrywa, bez względu na to, czy korzystają z niego w „tradycyjny sposób” czy też w „nowym stylu”. To właśnie synergia sprawia, że przyszłość NetBSD wygląda na tak świetlaną.

Skomentuj

Twój adres e-mail nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *