Deweloperzy NetBSD-7.0: Martin Husemann

Martin Husemann jest już trzecim deweloperem NetBSD, z którym zrobiliśmy wywiad. Na co dzień pracuje prywatnie i zawodowo z komputerami działającymi na NetBSD, a w projekcie jest odpowiedzialny za opiekę nad produkcją wydań.


 

Martin Husemann is now the 3rd NetBSD developer with whom we had an interview. He works privately and professionally with computers running NetBSD, in the project he’s responsible for the release engineering.


 

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

I have been a NetBSD developer since 2000 and served as a board member for four years. I am also the current „port-master” of sparc64 (and I think co-port-master for mac68k, despite my missing knowledge about the mac part of that platform).

I have given talks about my NetBSD work at several conferences and am right now travelling to EuroBSDCon 2015 in Stockholm.

More on NetBSD related activities below…

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

I have been using it basically from the very start of the project (where at that point it was unclear to me what the difference to 386BSD was and I think FreeBSD did not even exist yet).

I have to admit it was not a very conscious decision – I was looking for a router to get cheap but good internet access at home (which was basically impossible at that time). I made arrangements with a nearby university, but they would not allow fast modem access (which at that time was missing certificates for use in Germany), so it had to be ISDN.

None of the readily available systems (usable for routers) had proper ISDN support, so I picked a system that sounded good for routers and planned to work on ISDN support.

In the end I became part of the BISDN project and was made a developer to import that into NetBSD.

Initially, my platform was i386 only, but since I did compiler construction at university, I was interested in other architectures. I acquired a fully grown zoo of various machines and at one time had an example machine for all CPUs supported by NetBSD running.

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

For me the main reasons are

  • some special form of „purity”
    Not all code in NetBSD is clean and shiny, there is ancient code, there is ugly code, but on the other hand NetBSD is not quick in following all new hypes and dropping them quickly soon afterwards. This fits my personal taste and is interestingly different from many other development environments
  • all the same
    I use various architectures, and NetBSD on them is the same, everywhere.
  • works well enough (for me)
    Sometimes modern hardware lacks support for drivers, especially in the „pc” area. But common hardware is usually well supported.
  • will still work after years
    I sometimes run ancient binaries (some of which I lost the source for a long time ago). NetBSD provides very strong binary compatibility with its own old versions, and with other operating systems.
  • has a very friendly and helpful community

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

Yes, most of our servers run NetBSD. Mostly because (when I am in charge of the machine) NetBSD is the easiest solution for me.

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’ve already mentioned the ISDN story, at that time I provided patches and filed bug tickets (called PRs, problem reports in NetBSD/gnats land).

This is a good way to become involved, you poke other developers long enough until they get tired to commit your patches.

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

I work on the release engineering team, reviewing and processing pull-up requests from other developers for the release branches. „Normal” NetBSD developers are not allowed to commit changes on branches, we require a member of the releng team to review, apply and commit change requests.

I also do regular (mostly weekly) automatic test runs on a variety of hardware platforms. This is done on real hardware, we also do fully automatized tests on emulated machines and Xen domU instances. This provides very useful data by spotting regressions in -current early and pointing at machine dependent issues where things can be improved.

When a new hardware is added to the test runs, we usually start with more than 100 unexpected failures. After a while, we typically get that down to single-digit numbers. I talked about one special tricky case at AsiaBSDCon earlier this year – running a CUBIETRUCK board in big endian mode. There were lots of issues to fix, in all kinds of areas (kernel, libraries, development tools, tests). You can find it as well as other interesting talks about NetBSD here:

https://www.netbsd.org/gallery/presentations/

7. What’s your NetBSD workflow?

This depends a lot – many hardware drivers can only be debugged on the real hardware, so I usually netboot and debug using serial console, printf [function to print textual messages in dmesg(8) – editor’s note] and ddb [NetBSD builtin in-kernel debugger – editor’s note].

For other things, I use rump with gdb quite a bit, and for user land it is simply gdb. I always build with MKDEBUG=yes [build all executables with debug information – editor’s note] MKDEBUGLIB=yes [build all libraries with debug information – editor’s note], so all my installations have symbol information (in user land) available right away.

I have sometimes used qemu and its integrated gdb port, but not a lot.

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

Not a lot (unfortunately) recently – I have been very busy at work and plan to make it to my 25th wedding anniversary, so I cannot spend a lot of time with computers after work.

I am lucky to be able to do short-term things during working hours while waiting for compilers and similar things. This nicely fits the releng work.

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

My personal favourite is the much improved ARM support, see an example of this in my blog post about ARM SMP working:

http://blog.netbsd.org/tnf/entry/working_arm_multiprocessor_support

But for most people the DRMKMS work is the most important – it catches up with modern graphics on x86 machines.

Another highlight is the pretty modern toolchain we now have in our base: gcc 4.8 [4.8.5 – editor’s note] (and optional clang 3.6). This helps when compiling external software, especially C++ code.

As I am doing a lot of Firefox debugging: we can run full Firefox with debug info in the in-tree gdb (and we even have a wiki page describing how to do it [this is a kind of an insider joke – editor’s note]).

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

We have a list of projects on the wiki, but some of them are just strange ideas somebody (maybe me?) came up with some time ago. They are also of very different difficulty and require a great range of skills.

Add to this personal taste and it gets really complicated. So in short: I have trouble recommending projects to others.

It always helps if you have a problem in your own usage of NetBSD and go to fix that. This may be the design of the web page (why don’t we suggest something nice as an alternative?) or missing options to a program in the base system – provide patches, or try to discuss the idea. I think I’ve mentioned the friendly community before.

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

I hope to see more X/graphics related development, a lot of wlan enhancements and support for more hardware. My next pet for the test lab has just arrived:
an octacore arm 64bit machine.

I hope to be carrying a 64bit arm Chromebook running only NetBSD when I go to EuroBSDCon 2016!


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

Jestem deweloperem NetBSD już od 2000 r., w tym czasie byłem podczas czteroletniej kadencji członkiem zarządu. Jestem też obecnym opiekunem portu sparc64 (oraz częściwo współopiekunem portu mac68k, pomimo braków mojej wiedzy o komputerach Macintosh na tej platformie).

Byłem prelegentem nt. NetBSD podczas kilku konferencji, a w chwili obecnej wybieram się na EuroBSDCon 2015 do Sztokholmu.

Więcej o moich aktywnościach w projekcie napisałem poniżej…

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

Korzystam z tego systemu już od samych jego początków (w czasie, gdy jeszcze nie było dla mnie wyraźne różnienie względem 386BSD, a FreeBSD – o ile pamięć mnie nie myli – nie zostało jeszcze powołane do życia).

Przyznaję, że mój wybór [NetBSD] nie był głęboko przemyślany – po prostu poszukiwałem w tym czasie rutera celem podłączenia taniego internetu w domu (co było wówczas niemalże niemożliwe). Porozumiałem się wtedy z pobliskim uniwersytetem, niestety musiałem zadowolić się połączeniem ISDN (w owym czasie były problemy z certyfikatami na szybkie połączenia w Niemczech).

Żaden z gotowych systemów (używalnych na ruterach) nie miał odpowiedniego wsparcia ISDN, więc postanowiłem wybrać jedną z opcji dla ruterów i pracować nad funkcjonalnością ISDN.

W końcu zostałem deweloperem w projekcie BISDN i stałem się odpowiedzialny za integrację tego kodu z NetBSD.

Początkowo moją platformą było wyłącznie i386, ale odkąd zajmowałem się modelowaniem kompilatora na uniwersytecie, zainteresowałem się innymi architekturami. Stałem się posiadaczem swoistego zoo różnorakich maszyn – a w pewnym momencie miałem już po przykładzie z każdego procesora wspieranego przez NetBSD.

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

Moimi powodami są następujące rzeczy:

  • pewna wyjątkowa forma „czystości”
    Nie cały kod wewnątrz NetBSD jest czysty i błyszczący, mamy do czynienia także z kodem przedpotopowym, brzydkim, ale z drugiej strony NetBSD nie podąża za wszystkimi chwilowymi modami, porzucając je równie szybko w kolejnych fazach rozwoju. Ten aspekt odpowiada mojemu osobistemu gustowi i ciekawie się wyróżnia na tle innych modelów rozwoju środowisk.
  • zawsze takie samo
    Używam wielu architektur i na każdej z nich NetBSD jest wszędzie takie samo.
  • działa wystarczająco dobrze (dla mnie)
    Czasem brakuje sterowników dla najnowszego sprzętu, szczególnie na komputerach klasy PC. Natomiast typowy sprzęt jest dobrze wspierany.
  • działa nadal po latach
    Czasami uruchamiam pradawne pliki binarne (źródła do niektórych z nich straciłem dawno temu). NetBSD oferuje porządną kompatybilność binarną ze swoimi starszymi wersjami programów oraz innymi systemami operacyjnymi.
  • gromadzi wokół siebie bardzo przyjazną i pomocną społeczność.

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

Tak, większość moich serwerów działa na NetBSD. Głównie dlatego, że (gdy nadzoruję maszynę) NetBSD jest dla mnie najprostszym rozwiązaniem.

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

Wspomniałem już o przygodzie z ISDN, w tym czasie dostarczyłem łatki i zgłosiłem błędy (żargonowo zwane PR – ang. problem reports – w systemie zgłaszania problemów gnats w infrastrukturze NetBSD).

To jest dobry sposób, by się zaangażować: naprzykrzasz się innym deweloperom wystarczająco długo, by commitowali twoje łatki.

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

Pracuję w zespole produkcji wydań, przeglądam i przetwarzam pull-upy (propozycje wciągnięcia łatek) do gałęzi stabilnych (wydań) od innych deweloperów. „Typowi” deweloperzy NetBSD nie mają uprawnień do commitowania zmian w tych gałęziach, stąd wymagana jest asysta inżyniera wydań celem przeglądu, zatwierdzenia i złączenia łatek.

Uruchamiam również regularne (zazwyczaj raz w tygodniu) automatyczne testy na różnych platformach sprzętowych. Jest to robione na prawdziwym sprzęcie, wykonujemy również pełne, zautomatyzowane testy w maszynach wirtualnych i instancjach Xen domU. Dostarcza to bardzo przydatnych danych poprzez wczesne wykrycie regresji -current [wersji rozwojowej – przyp. tłum.] i ekploatowania błędów zależnych od architektury, pozwalając na całościową poprawę jakości.

Tam, gdzie nowy sprzęt jest dodany do testów, na początku zazwyczaj mamy ponad 100 niespodziewanych błędów. Po chwili zazwyczaj przypisujemy to liczbom jednocyfrowym. Rozmawiałem w tym roku na AsiaBSDCon o pewnym wyjątkowo wrednym przypadku – o uruchamianiu płyty CUBIETRUCK w trybie Big endian. Było wiele kwestii do naprawienia we wszystkich rodzajach obszarów (kernel, biblioteki, narzędzia deweloperskie, testy). Można je znaleźć wraz z innymi ciekawymi slajdami na temat NetBSD tutaj:

https://www.netbsd.org/gallery/presentations/

7. Jaka jest Twoja organizacja pracy z NetBSD?

To zależy od różnych rzeczy – wiele sterowników może być debugowanych tylko na prawdziwym sprzęcie, więc zazwyczaj netbootuję i debuguję korzystając z konsoli szeregowej, wywołań printf [funkcja do wypisywania wiadomości tekstowych w dmesg(8) – przyp. tłum.] i ddb [debuger kernelowy w NetBSD – przyp. tłum.].

Do innych celów sporo wykorzystuję rump z gdb, a dla pracy w przestrzeni użytkownika jest to po prostu gdb. Zawsze buduję źródła NetBSD z flagami MKDEBUG=yes [zbuduj] i MKDEBUGLIB=yes, więc wszystko, co instaluję ma informację o symbolach (w przestrzeni użytkownika), która jest dostępna od ręki.

Czasami korzystałem z qemu i zintegrowanego z nim gdb, ale niezbyt dużo.

8. Ile czasu zajmuje Ci praca w projekcie NetBSD?

Ostatnio (niestety) niezbyt dużo – mam bardzo dużo pracy zawodowej i planuję ją skończyć przed moją 25. rocznicą ślubu, tak więc nie mogę spędzać po pracy zbyt dużo czasu przy komputerze.

Mam szczęście, że mogę wykonywać krótkie zadania w godzinach pracy w czasie, gdy czekam na kompilację itp. To bardzo dobrze pasuje do pracy inżyniera wydań.

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

Tym, co mnie osobiście podoba się najbardziej jest mocno ulepszone wsparcie platformy ARM, na blogu Fundacji NetBSD można przeczytać o zgodności tych procesorów z naszym SMP [ang. Symmetric MultiProcessing – wieloprocesorowość symetryczna – przyp. tłum.]:

http://blog.netbsd.org/tnf/entry/working_arm_multiprocessor_support

Dla większości osób progres w rozwoju DRMKMS jest najważniejszy – nadgania on możliwość użycia nowoczesnych kart graficznych na platformie x86.

Inną ważną rzeczą jest dość nowoczesny toolchain, który obecnie mamy w systemie bazowym: gcc 4.8 [4.8.5 – przyp. tłum.] (i opcjonalnie clang 3.6). Jest to pomocne, gdy kompilujemy oprogramowanie zewnętrzne, zwłaszcza kod C++.

Jako że sporo zajmuję się debugowaniem Firefoksa: możemy uruchomić pełnego Firefoksa z symbolami dla gdb z systemu bazowego (i mamy nawet stronę na wiki, opisującą jak to się robi [to jest pewien rodzaj żartu środowiskowego – przyp. tłum.]).

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

Mamy listę projektów na wiki, ale niektóre z nich są po prostu dziwnymi pomysłami, na które ktoś (może ja?) kiedyś wpadł. Różnią się one także znacząco pod względem stopnia trudności i wymagają różnorodnych umiejętności.

Jeśli dodamy do tego kwestię osobistego gustu, sprawy naprawdę zaczynają się komplikować. A zatem w skrócie: mam problem z polecaniem projektów innym.

Dobrze jest napotykać problemy samodzielnie w użytkowaniu NetBSD i pokonywać je. Może to być model strony internetowej (czemu nie zasugerować czegoś fajnego jako alternatywę?) albo brakujące opcje programu w systemie bazowym – dostarczenie łatek lub też próba omówienia problemu. Chyba wcześniej już wspominałem o przyjaznej społeczności.

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

Mam nadzieję zobaczyć więcej usprawneń w obsłudze X Window i grafiki, dużo więcej /graphics, wiele ulepszeń w dziedzinie wlanów i zgodności z większą ilością sprzętu. Właśnie przybył mój kolejny ulubieniec do mojego laboratorium: Octacore wyposażony w 64-bitowy procesor ARM.

Mam nadzieję zabrać ze sobą na EuroBSDCon 2016 Chromebooka wyposażonego właśnie w taki 64-bitowy ARM-owy procesor.

Skomentuj

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