The NetBSD Project announced Monday that release 1.6.2 of the NetBSD operating system is now available, with binary distributions for 40 architectures. NewsForge interviewed Luke Mewburn of the NetBSD Core Group and asked him about the NetBSD project in general, the long awaiting release 2.0, and a lot of technical and organizational issues.
Interview with NetBSD’s Luke Mewburn
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
“Generally NetBSD hasn’t run the same level of marketing campaigns that other projects have to gain new users; we develop a good product that speaks for itself”
Wow. These guys really try to avoid hype – even when they’re promoting themselves. No superlatives in this interview.
I’m just kidding in the Topic, NetBSD is free
. I just wanted to say that it’s worth a test. So far NetBSD is the only OS i tried wich is not in the way. Sometimes i think the big difference between NetBSD and for example Linux or Windows is that it is not grown but designed.
Karsten
Well out of all the BSD’s, I think FreeBSD is the one that seems to be stuck. They’ve been trying to get the 5.x line to get off the ground for 3-4 years now and everytime it seems like they are getting somewhere, more delays appear. Now that supposedly the next version is going to be stable, I would really like to read an interview on where they are, where they are going, how promising is the new technology, and how the time schedule is looking.
Now that supposedly the next version is going to be stable, I would really like to read an interview on where they are, where they are going, how promising is the new technology, and how the time schedule is looking.
The technology in the upcoming new FreeBSD branch is very promising. There are a few reasons for the delays, first of all being that the FreeBSD team continues to add features outside of what is fundamental to 5.x. Improved SMP scalability, scalable kernel assisted userland threading, modular and extensible security framework and new platform support are the major goals for 5.x, but many minor projects are being integrated in parallel with these major goals.
The other major issue holding back the release of the new production branch is the fact that the SMP architecture being pursued isn’t the most intuitve for most people who might be interested in working on it. It is a fine grained mutex model that sprinkles locks at various critical places in the kernel allowing for a greater number of kernel threads to run simultaneously, making efficient use of SMP hardware. Although the issues surrounding this model are well understood, and the debugging tools are excelent, there are times when a mutex model can be a real pain in the butt to work with, especially lock order reversals, and priority inversions in situations when a lock may need to be aquired by several threads in order to complete one opperation.
In order to avaiod such issues, a thorough understanding of all locking and the order in which they take place must be known ahead of time in order to prevent evilness from occuring. This is one of Matt Dillon’s primary issues with the direction that FreeBSD 5 is taking. It’s definately capable of a very high performance, but it’s a time consuming pain in the ass to actually implement with the resources they have at hand.
The major focus for the remainder of FreeBSD 5.x is mostly going to be continued locking up of the various kernel subsystems. They new security framework is nearling production readyness, as is the new M:N threading system, and many of the major subsystems are already locked. Except for things like NUMA that are only important to very small numbers of people, and other things like support for MMUless CPUs (something that I think should be illegal in this day and age
FreeBSD is technologically comparable to Linux, with both systems being more mature than the others in certain areas.
The FreeBSD developers have made mistakes for sure, but none are so fatal as to delay the release of the new production branch in the very near future, or to cause such serious setbacks as to make them irrelevant. The most painfull work is almost behind them now, and the future is looking bright.
Linux has taken a similar approach to SMP; using fine grained locks to increase the number of threads running inside the kernel. However, the Linux kernel has a smaller variety of locks, and only uses them in and SMP environment. The Linux kernel also makes use of a technology called RCU; ‘read copy update,’ which is a very simple concept (one that SCO claims it owns, but I could swear I’ve thought of something similar ages ago, as have many of my fellow idiots).
When a shared resource cannot be mdified by more than one thread at any given time, but must be read by several, each thread reads in a copy of the resource, and only later updates the original with any changes. This helps to solve the sharing problems, but really kills some types of performance.
You gain in the short term, but lose later when it comes time to do the updating. Basicall swapping one bottleneck for another. FreeBSD (I believe) does not have a simillar capability, nor am I sure it’s really a good idea. The Linux and DragonFly folks seem to think it is, but many FreeBSD folks seem to think otherwise. Time will tell.
Do you have any information about the internals of the upcomming SMP support in NetBSD 2.0? Is it the classic BGL (big giant lock) or something more sophisicated?
OTOH, I know that the threads implementation in NetBSD is a pure MxN “scheduler activations” (SA) approach that follows closely the original design proposed by Anderson et. al. Details here:
http://web.mit.edu/nathanw/www/usenix/
I am not sure though how well the SA implementation in the NetBSD cooperates with the SMP implementation. (In the FreeBSD campus they chose to depart from original design of SA and come up with the notions of KSEs, KSE groups, etc. I don’t know if this decision of theirs was based on SMP issues or not.)
Thanks
Stelios
The SMP that will be in NetBSD 2 is BGL. Or at least -current still is using it, and I don’t think they’ll be coming up with anything better in time for 2.0.
I think there are some places where the kernel operates with finer-grained locks and doesn’t use BGL, but I think they are very few.
The thing with SA and SMP, as I understand is, that currently they don’t really have to co-operate that much, because SA doesn’t make much use of SMP. I don’t remember the details; the problem however is that they should rewrite the whole scheduler to really make it work… but I haven’t seen any discussion on tech-kern about this for a long time.