EuroBSDcon 2013 Developer Summit Special Status Report
This special status report contains a summary of the discussions from the various working groups at the EuroBSDcon 2013 Developer Summit. The FreeBSD Project organizes developer summits at various events, typically at the major BSD conferences, so that developers can meet and discuss matters in person.
- Desktop
- Developer Summit Track
- DNS
- Documentation
- Embedded Platforms
- Networking
- Ports and Packages
- Security
- Toolchain and Build Systems
- USB
- Vendor Discussions
- Virtualization
- ZFS
Desktop
| Links | |
| Summary | URL: https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&target=DesktopWG-Summary.pdf |
Contact: Kris Moore <[email protected]>
In the Desktop working group, Kris Moore summarized the changes
made over the last few months in the world of PC-BSD. Builds
based on the freshly released 9.2-RELEASE are in
progress, and future builds based on 10-STABLE are
coming soon. The plan there is to track the 10-STABLE
branch until it becomes 11-STABLE. Kris also described
the rolling release
model they have switched to. This
approach leverages freebsd-update(8) to provide rolling
updates for the base system (that is, the kernel and the
userland utilities) and in parallel with that, pkg(8)
is employed for the packages, especially for the desktop
applications. It was also reported that the PC-BSD staff has
improved the ZFS integration of their tools, including the
installer. Another highlight of the upcoming PC-BSD releases is
that they will include Gleb Kurtsou's PEFS that provides user
encryption of user home directories with PAM-based
authentication.
Next, the current in-progress items were reported and
discussed. The sysutils/pcbsd-utils and
sysutils/pcbsd-utils-qt4 ports have been recently added
to the ports tree that contain all PC-BSD developed tools and
utilities, where the former features the command-line and the
latter features the GUI-enabled versions of the corresponding
programs. The PC-BSD developers have also been working on a
life-preserver
ZFS command-line and GUI utility, which is
still in heavy development. The purpose of these tools to
leverage ZFS for snapshot and replication functionality as a
backup solution.
Finally, the plans for PC-BSD�10 were summarized. The PBI package format that PC-BSD employs in now under revision and will be updated to use pkg(8) repository to build PBIs and provide better integration for server PBIs. As part of this effort, it will also be investigated whether it is possible to run PBIs without actual installation. pc-sysinstall will have a text-based front-end. This is going to be basic at first, but later it will provide a command-line interface to do installation with the pc-sysinstall backend.
Developer Summit Track
| Links | |
| Playlist of the talks | URL: http://goo.gl/2EF30C |
Contact: G�bor P�li <[email protected]>
Since 2011, the FreeBSD Developer Summit Track has become an essential part of BSDCan and EuroBSDcon conferences. It provides the developers and community members an opportunity to tell about their latest projects, brainstorm on solutions to a hard problem, train attendees to use a new tool, make observations about a FreeBSD development process and how to improve it, talk about how their company uses FreeBSD, or coordinate activities. One can also catch reports from the Google Summer of Code students at the European instances.
At EuroBSDcon 2013 we had talks on the following topics: superpages for ARM, an SDIO stack, porting GlusterFS, unattended encrypted kernel crash dumps, adding Capsicum support for compression services, an intelligent download management service, LLDB, improvements in packet forwarding, multipath TCP support, a FreeBSD-based network simulation environment, and finally, porting Mirage, an operating system written in the OCaml functional language, to FreeBSD. The playlist of the talk recordings (audio with slides and demonstrations) can be found above at the entry's URL section.
DNS
| Links | |
| Summary | URL: https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&target=20130928-eurobsdcon-dns-summary.pdf |
Contact: Erwin Lansing <[email protected]>
FreeBSD�10 is not going to have BIND any more, it is going to be based on unbound(8) and LDNS, both have been imported into the base system, along with a small host(1) replacement. LDNS also comes with drill(1) that needs a simple wrapper to make it compatible with the dig(1) command-line interface. OpenSSH can use LDNS for checking SSH fingerprints which also implies that DNSSEC validation is enabled by default. Note that unbound(8) will be hidden, it will be a local resolver only. For other purposes, one shall have to install its version in the Ports Collection instead.
For the next major version, FreeBSD�11, there will be more time to find an alternative to BIND, so it was also discussed in the working group what the requirements would be for an ideal DNS implementation. Based on the results, what we want is a caching, validating resolver library, which is compartmentalized by Capsicum, supports per-user policies and integration with the Casper daemon, BSD-licensed, has a low footprint, fast, and thread-safe. But the most important factor here is that we want to standardize the API towards application level, so we can actually report back to the user on what happens in relation with DNSSEC operations in an informative way. There have been many proposals for that, like the get-api from Hoffman, or draft-hayatnagarkar-dns-ext-validator-api for libval, but it is currently being standardized by members of IETF. What we want to do is to contact those people and make sure that FreeBSD�11 will become a standard reference implementation.
Documentation
| Links | |
| Summary | URL: https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&target=DocWGSummaryReport.pdf |
Contact: Benedict Reuschling <[email protected]>
We wanted to try something new this year, so instead of doing a lot of talk, we focused on doing actual work, and fixing PRs in collaboration with the attendees who participated the working group. It turned out that it did not work so well, because we had a lot of things to discuss, but some issues were fixed eventually.
There was a huge demand for a new webpage: it has to be more modern to catch up with the recent trends. It should provide dynamic content like blogrolls, twitter feeds, etc. Currently, the problem is that the web site lacks many basic functionalities, such as the search option is not working properly. Isabelle Long has been working on integrating the DuckDuckGo search engine into the web site, and she will hopefully commit the necessary changes soon. There are other problems, for example, there is no link to the FreeBSD Forums, while they have established themselves as another support option for users.
Then the representatives of the FreeBSD Foundation joined our group and showed us what they have been working on. They showed a design proposal for their website. Their suggestion is to make the FreeBSD Foundation website look similar to the FreeBSD Project website, so these pages could be connected visually. Judging from the fancy proposal they have shown us, it will probably take a lot of infrastructural work to make our website look closely to the Foundation's. As a result, we agreed to form a team for the new website, assembled from Project members internally, to ensure that the new design satisfies expectations from all sides, e.g., administration, functionality, security, and so on.
Another thing that we have talked about was the on-going print edition work of the FreeBSD Handbook. We have promised to complete the effort by BSDCan this year, but apparently we could not make it in time. Dru Lavigne went through the whole Handbook and identified many problems to solve (outdated content, unrelated sections, etc.) in order to have really good content ready for the printed edition. We need more content and reviewers, so if you are looking through the Handbook and meet an outdated section, please contact the Documentation Team. You do not have to send patches right away, it is enough to provide a few sentences or a paragraph only to improve or add the description for the given system functionality. The Documentation Team will then take care of putting them in the Handbook or the relevant documents.
We also discussed the idea of having maintainers assigned to specific sections and chapters of the Handbook, similarly to the policy implemented in the Ports Collection, so users and related PRs can be forwarded to them, and the maintainers take care of keeping those areas in the documentation up-to-date. The goal is to reduce the overall workload on the Documentation Team.
Finally, it was mentioned at the vendor group that we want to revamp our actual workflow for translating documents. We are currently doing the translation work by using a standard editor translating sentence by sentence, which is tedious. In addition to that, most of the translator teams are really small, so it is hard for them to catch up with the changes in the English documents and they become outdated quickly. We have briefly talked with Gavin Atkinson about removing really outdated documentation from the doc tree, like the ones who are still reflecting FreeBSD�5.x or so. In summary, the main objective is to have a system that helps by keeping track of translations, like the PC-BSD developers are doing: we are aware that Kris Moore has written some scripts to extend the standard tools like Pootle to improve their efficiency. It would be a huge win to see how many sentences are already translated, how many are left to translate, how many of them could be reused using such a system. Another benefit of these systems is that they can provide an interface for casual contributors to provide translations which can be then checked and committed by the documentation developers.
Embedded Platforms
Contact:
Warner
Losh
<[email protected]>
Contact:
Brooks
Davis
<[email protected]>
The discussion on embedded platforms was started in Cambridge a month earlier, where it was kicked off with a presentation by BrilliantService on their Viking operating system for a head mount augmented reality display. We then had a discussion of board bringup and the related topic of kernel minimization. This was followed by a long discussion of system image creation and what is required to promote some embedded platforms to Tier-1 status. Finally, we discussed power management.
The discussion of Tier-1 status for embedded platforms, particularly Raspberry-Pi, identified a number of things required to make this possible. In addition to some driver improvements and stabilization efforts, we need to build images as part of, or derived from the products of the current release build process. We also need to be building packages (Stacey Son is working on making this happen for ARM and MIPS64). We will also need some form of binary updates. Initially this will probably be done via freebsd-update(8), but in the long term this will likely be too slow to be practical. Further discussion of this topic was a major thread at the EuroBSDCon developer summit.
The power management discussion was wide ranging and concluded that we do need better power management infrastructure and that we are not entirely sure what that looks like. We certainly do need some way to represent the power management bus/device trees that differ from the conventional models of attachment in our device infrastructure. We also need smarter scheduling to allow us to do things like steer all interrupts away from certain cores so they can be shut all the way down.
In Malta, the first thing we talked about was trying to get better goals, use cases for the external toolchain support so that we have the work done by FreeBSD�11, where any architecture that supports can be built by using external toolchains. We talked about different ways for an architecture that does not have support for a native toolchain to work in the QEMU-based package building infrastructure. By FreeBSD�11, we also want to make sure that it was all well-documented so that users will know what is and what is not supported on a given platform.
Next, we had a long discussion about the auto tuning changes that Alfred Perlstein did recently. They are great for machines with a gigabyte or more memory, but they are bad for machines that almost have no memory, so Adrian Chadd has volunteered to fix this (see the slides for more details).
We talked a lot about what to do around the ARM port in FreeBSD�11, and we have set some goals for 11 in this area. Some of the highlights are as follows. We want to have the ability to boot one kernel on any armv6 platform — currently there are a number technical roadblocks to that. We want to keep the armv4 and armv5 support in 11 until there is some particular reason not to do that. One of the biggest tasks probably, since we are moving to Clang, would be the external toolchain item. Besides that, the armv6 will grow hardware floating-point support, we are hoping to have Symmetric Multi-Processing (SMP). And we talked rather extensively about some of the release engineering tasks we will have to do: we need to have images for popular boards, such as Raspberry Pi and BeagleBoard. We would like to have some work done in this area in the 10.1 timeframe. We want to get packages spun up for ARM and MIPS, as well as setting the infrastructure up for freebsd-update(8). It was also briefly mentioned that there is no good GPU support on ARM right now, and that is on the FreeBSD side. We need a strategy that has the least disadvantages, which might be adopting the Android ABI and let the Android blobs to be dropped in. There are a number of challenges in this case.
In addition to that, we talked about MIPS and various FDT
issues. The key problems for the latter were that we need
better clock and power support and there are separate
domains
from the device tree, and they need to be
treated as such. Also, GPIO and pinmux are inconsistent
between the different releases, we need to fix that. We also
talked about Arm64, where there are lot of things to do. The key
though is find out (with the assistance of the FreeBSD Foundation)
who is interested in Arm64 among the vendors and how to
collaborate with them. Since the Foundation has the contacts
and the related NDAs to the largest consumers, probably they are
in the best position to drive this effort. Together with the
Semihalf people and the ARM representative at the summit, Andrew
Wafaa, we have conluded that Arm64 support is not far away from
the things we have now support for in the kernel. It turned out
that it is mostly about how we organize the source tree and
similar minor issues.
Networking
| Links | |
| Notes | URL: https://wiki.freebsd.org/201309DevSummit/Networking |
Contact:
Lawrence
Stewart
<[email protected]>
Contact:
Gleb
Smirnoff
<[email protected]>
Andr� Oppermann gave a status report on his current work on the interface between the network stack and the drivers. He is planning to publish a formal documentation on the stack-driver boundary and split the ifnet structure into separate, stack- and driver-owned sections. All drivers will be adjusted to this new world order, and a call for feedback will be posted to the respective mailing lists. This change is being implemented in the projects/ifq Subversion branch, supervised by Ed Maste on behalf of the FreeBSD Foundation as sponsor. Andr� is close to completing his TCP-AO work, and working on moving the IPsec code into a pfil(9)-based kernel module. Gleb Smirnoff came up with the problem of implementing a lightweight reference counting to avoid dangling pointers, and Alexander Chernikov started a discussion on the routing performance.
Another highlight of the networking stack working group was the discussion on testing, where everybody agreed that developers should communicate with companies able to test the performance with different workloads. Olivier Cochard-Labb� (from Orange) and Alexander Chernikov (from Yandex) have already shown interest in this effort, while the Netflix staff (Lawrence Stewart, Adrian Chadd, and Scott Long) confirmed that they have access to a TCP-heavy production workload. On a related note, it was added that Netflix is looking to host developer summits focused on networking in Los Gatos, California, on a semi-regular basis.
Ports and Packages
| Links | |
| Summary | URL: https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&target=20130928-eurobsdcon-ports-summary.pdf |
| Notes | URL: https://wiki.freebsd.org/201309DevSummit/Ports |
Contact: Erwin Lansing <[email protected]>
We had one full presentation by Allan Jude, a quick overview of what they did for the PC-BSD CDN (Content Delivery Network). For example, it uses the --delay-update flag for rsync(1) to make it more atomic, uses a lot of ZFS functions (e.g., replication, snapshot management) and implements automatic mirror selection. It was a quite interesting talk, and featured some interesting ideas that we could pick and use for the FreeBSD package distribution network. This was then followed by a talk by Jeremy Le Hen, who talked about stack protection (SSP). It will be enabled by default in FreeBSD�10.x on amd64 and i386 platforms, but can be turned off by the SSP_UNSAFE knob. Conversely, it is not enabled by default on 9.x, but can be turned on by the other knob, WITH_SSP_PORT. This should work on amd64, and it has no effect on i386.
Baptiste Daroussin talked about staged installs which was committed recently. Every other package system does that, now we do it as well. It brings a lot of improvements, such as we can catch packaging list errors earlier, before the package is actually installed on the file system. There the NEED_ROOT knob can be used if a port requires root privileges for building and packaging. It also simplifies most of the logic employed at the build farms, because many of the checks can be automated this way, catching broken plists and helping to get rid of the special post-install scripts. It lays the foundation for some new features we want to add in the future, for example implementing sub-packages. Having sub-packages enables building packages once and putting files into separate smaller packages which can be then installed individually. Compared to all the other options, it is turned off by default, and ports are slowly converted to this format one by one — however, at some point, we might say that ports not converted to support staging will be removed. Actually, this would help us find out which ports in the tree are not used any more.
Then there was a discussion about what to do next. We have been talking about package sets for at least three years now, it seems we are finally able to do it. We are going to try to do a security branch, together with reviving the ports security team, in cooperation with the Security Officer, Dag-Erling Sm�rgrav. We are aiming for quarterly releases and weekly security updates for those releases in the security branch. This has been an ongoing plan for three years, because we needed many things to happen before we could proceed, such as moving away from CVS, introducing new-style binary packages, deploying new build clusters. We have finally got them all, and we can actually do it now with the pkg-test setup. So, we are hoping to start with the first quarterly release in early November.
We had a long discussion about removing support for old-style binary packages now that we have pkg(8). Staying compatible with pkg_install(1) hinders the introduction of new features, e.g., sub-packages mentioned above. We cannot really add those new features as the old tools will not support them and we cannot expect ports to work with two different package formats at the same time. We do not want to surprise our users too much, but it turns out there is an easy migration path. Among many others, an advantage of pkg(8) that it can interoperate with various third-party applications, e.g., puppet and chef. It is still a POLA violation, so we should be careful of how the actual transition is made. We should give a lot of warning to the users, specially in case of large installations, where there are custom scripts to work with ports and packages. The date for throwing the switch has been set for six months, that is, April 2014, which fits nicely with the End-of-Life date of 8.3-RELEASE, the last release that does not include pkg(8). So, at BSDCan next year, we can hopefully celebrate the switch from pkg_install(1).
Finally, we discussed issues related to package naming. The problem is that certain ports have the same name and they rely on this, so currently we have LATEST_LINK to work around this behavior. We should educate people to make better use of PKGNAMESUFFIX to make sure that all affected ports have a unique name. To encourage this, we should set up automated checking to warn people about having packages of the same name. PKGNAME must be unique across categories, so when one uses pkg-add(8), the system has to know which package to choose for install. This will improve things for better handling of options, adding package flavors and implementing sub-packages.
Security
| Links | |
| Summary | URL: https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&target=201309+DevSummit+Security+Report.pdf |
| Notes | URL: https://wiki.freebsd.org/201309DevSummit/Security |
Contact: Dag-Erling Sm�rgrav <[email protected]>
In the security working group, we had four items in the agenda. First of all, we started with the current state of /dev/random. There were a number of known entropy harvesting bugs that have been fixed, for example feeding a lot of zeroes from the network stack. We have a pluggable random generator framework and we have a number of plugins for it, Yarrow is one, and the RDRAND, Padlock are two others, we have one that blocks and one that panics, and few coding examples and so on. For 10, we are going to backtrack and remove RDRAND and Padlock backends and feed them into Yarrow instead of delivering their output directly to /dev/random. It will still be possible to access hardware random number generators, that is, RDRAND, Padlock etc., directly by inline assembly or by using OpenSSL from userland, if required, but we cannot trust them any more. In addition to this, we want to collect more entropy early in the boot process, because we want to get rid of the initrandom script that feeds mostly static data into /dev/random and pretends that is actually entropy, when it is not. Pawel Jakub Dawidek has a patch which has been floating around and doing some analysis on this, we finally got some numbers for it. This patch feeds the amount of time it takes to attach a device into /dev/random and it turns out that one can get about 4 good bits of entropy from each device. Also, we should have the installer fill up the /entropy file on the newly installed system, so we have something when the system starts up for the first time. And there is also the matter of (especially with virtualization and cloning, which is becoming more and more common) ensuring that the clones diverge quickly enough. As an example, we discussed having the installer generate SSH keys. But a problem is that if you install a VM and it generates the SSH keys, and then it is cloned, all the instances will have the same keys. So when the individual VMs are started and they do not have enough entropy harvesting early in the boot process, then keys are generated based on the entropy that the installer has dumped during the installation process, which is as almost as bad. The device attach patch helps with that.
The next item was package signing. We have a short-term solution for 10 until a more professional one is developed. In this design, the package builders do not have the keys, instead they submit hashes to a signing server after they are done, and the signing server returns the signature. We are simply going to ship the fingerprints with the base system under /etc/pkg/fingerprints. If we need to revoke a key, or distribute a new key, we will just issue a new FreeBSD Security Advisory (which should be done anyway), and will have freebsd-update(8) distribute an update that moves the key from the trusted directory to the revoked directory and adds the new key to the trusted directory. When launched, pkg(8) looks into those directories, loads all the keys it finds, and will accept a packages if it is signed by at least one good key and no revoked keys.
Package signing was followed by mitigation by Sofian Brabez. He has stackgap optimization and mmap() randomization ready to be included in 10, but turned off by default. Stackgap randomization adds a random amount of empty space at the top of the stack, so that an attacker cannot just make assumptions about the actual stack layout of the applications in case of buffer overflows. The problem with stackgap randomization is programs like Varnish, that have many threads and therefore very small stacks in order to avoid running out of stack space, will run out of stack space. This is because stackgap randomization will increase the size of the stacks. mmap() randomization inserts a random gap between consecutive mappings for the same purpose. Stack protection (SSP) can now be enabled by default. The problem is if it is turned on by default, a lot of ports will break. It is because GCC includes an additional object file during linking for checking the canary words, and this apparently interferences the way some ports build. libc is now a linker script and not just a .so file, therefore the linker will always know how to handle this. ldbase randomization was also discussed, but it has not been implemented. It randomizes where the libraries are loaded by the run-time linker.
The final item on the agenda was VuXML and portaudit. We have a number of shortcomings with VuXML. One of them is that the portaudit tool is based on string matching which is unreliable, especially when we have ports that are renamed and multiple ports, different versions of the same software. In addition, there are many errors in the actual data, especially a very common error is to have > instead of >=. Also, the auditing tools do not verify the base system version. We have VuXML entries for Security Advisories but they are unused because of this. One of the reasons for that is that the kernel patch level does not necessarily reflect the patch level of the userland, because freebsd-update(8) does not update the kernel patch level unless the actual update affects the kernel. So we are going to start including CPE information in ports. That is the Common Platform Enumeration, and that is a NIST standard for uniquely identifying software packages, versions, variances, even port revisions. The point of using CPEs is that it is unique, not tied to the name of the port so we can have multiple ports with the same CPE without any trouble. We will store it as annotations for pkg(8) packages. CPEs published by NIST can be simply pushed directly to VuXML and we do not have to do the matching ourselves any more. The specification of CPE includes a matching algorithm and is shipped with a reference implementation. FreeBSD�10 is going to install a script under /libexec that prints the userland patch level, and freebsd-update(8) will update that script so it will be possible to verify the userland patch level as well.
Toolchain and Build Systems
Contact: Brooks Davis <[email protected]>
The discussions on toolchains and build systems in Malta started a month earlier in Cambridge. There, the main themes were source code analysis, the status of replacing GCC, and a discussion of packaging the base system. Notes on these and other topics can be found on the session page on the wiki.
Source code analysis took several directions. We discussed adding annotations to the source tree to support various advanced analysis tools. There was general agreement that this has some downsides if they get out of date, but that it is useful so long as the annotations are verified. Most proposed annotation require some sort of LLVM support, so we discussed the process of integrating LLVM analysis into the build framework. We also discussed the idea of running various analysis tools as part of the tinderbox framework.
In the context of replacing GCC, we discussed David Chisnall's plan to stop building GCC and libstdc++ on systems where Clang is the default compiler (this has happened). Further, we plan to migrate all existing platforms to Clang or an external GCC by 11. External toolchain support currently works with Clang, but not GCC.
Finally, Baptiste Daroussin discussed his proposal to package base with packages as a replacement for the current tarballed distributions. Once this is done, it is possible to do the tasks freebsd-update(8) does including upgrades and detecting changed files in a more operating-friendly way. Using pkg(8) as a replacement for freebsd-update(8) is not a general solution yet, as package signing and delta support is required to make it viable.
In Malta we covered two main topics: the overall status of non-permissively licensed (GPL-licensed) software in the base system, and a detailed discussion of the status of external toolchain support. We also decided that a future meeting should discuss making incremental builds practical and that we should run a working group specifically on the kernel build system at a future conference.
About half the meeting was consumed by a detailed walkthrough of the GPLinBase wiki page (see links). A number of areas need modest amounts of work and binutils replacement needs quite a bit. In practice, we believe we have most of the required pieces in either the ELF Toolchain project or LLVM, but the work of identifying pieces and testing them with base and ports will take some time.
We then discussed the status of Warner Losh's work on adding support for GCC to the external toolchain infrastructure and on upstreaming patches to GCC. Fortunately, the majority of our changes to GCC in base are x86 modernization which is no longer required in new releases. In practice, we have about 2000 lines of changes that should be merged and a few hundred more we should add to cross toolchain ports. In addition to creating a modern cross GCC, the external toolchain support needs work due to differences in support for -B and possibly --sysroot between Clang and GCC. Further discussions of external toolchain support occurred in the Embedded session.
USB
Contact: Hans-Petter Selasky <[email protected]>
In the USB working group, Hans-Petter Selasky summarized what happened to FreeBSD's USB stack during the last year. He mentioned that there were no serious issues, while the USB driver support improved on both device and controller fronts. He also noted that many systems have started to use the USB stack itself outside the FreeBSD kernel, for example DragonFly BSD. Hans-Petter briefly walked through the list of ideas on how to improve USB support further: he wants to import more Linux USB serial port and Ethernet device drivers into userspace, which can be then accessed through his webcamd(8) daemon, move the NDIS (Ethernet and wireless) USB wrapper to userspace, and implement emulation of the Linux USB file system at character device level via the Cuse4BSD-based daemon, also in userspace.
The summary was followed by the discussion of how to fix the detach issues experienced in case of USB wireless and Ethernet devices, initiated by Adrian Chadd. In addition to that, some DWC OTG were discussed, such as the need for implementing DMA support and expose it to more testing for all device speeds, not only for Ethernet and memory sticks.
Vendor Discussions
| Links | |
| Summary | URL: https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&target=20130928-eurobsdcon-vendor-summary.pdf |
Contact: Erwin Lansing <[email protected]>
First, Justin Gibbs, on behalf of the FreeBSD Foundation, gave a status update. A major change was that previously we had only a single part-time employee, Deb Goodkin. Now we have a two full-time technical staff members involved in some of the current projects, such as Kostik Belousov who is still working on improving our X.org support. They are also helping out with improving continuity within different teams like the Release Engineering Team and the Security Team. We also employed Glen Barber as a system administrator who is working with the FreeBSD cluster administrators to supervise the Project's machines, and he is also helping out with release engineering. Ed Maste has been employed part-time as a project manager to oversee the progress of the Foundation-sponsored projects. But we are hoping to get more people involved, especially on the sides of administration and marketing.
We had a presentation by Daichi Goto about his company in Japan, called BSD Consulting, Inc. He consulted for a company where he wanted to solve problems using FreeBSD but the company did not allow him to do that as they could not get commercial support for FreeBSD. So he started his own company solely for this purpose, which for example, includes hardware certification.
There was a discussion revolving around that current status of our documentation and web site, especially in Japan, where most of the people do not speak English very well. In the rest of the time we had a long but fruitful discussion about smaller projects, for example incorporating more bug fixes related to Infiniband into releases. In general, it would be useful to backport not only security fixes but major fixes and release backported erratas for the releases. Then we talked about nanobsd support, making it more visible and accessible to the potential users. Next, we talked about promoting ARM and MIPS platforms to Tier-1, providing more translated documents and testimonials, documentation to attract news users for FreeBSD and reach out for them: how to write problem reports, debug the kernel, etc. In connection to that, PR triage was also mentioned, where the goal is to provide an answer for every incoming bug report in a couple of days. As usual, Java was also on the menu, where it seems they are swinging back to OpenJDK being the default in 1.8.
Virtualization
| Links | |
| Summary | URL: https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&target=eurobsdcon_summary.pdf |
| Notes | URL: https://wiki.freebsd.org/201309DevSummit/Virtualization |
Contact: Peter Grehan <[email protected]>
In the virtualization working group, Peter Grehan gave a status
report. In FreeBSD�10, a lot of pieces of work have been
going on for the last two years, so we are slowly getting the
guest support of Xen, PHVM, Hyper-V drivers, and
bhyve(4) into 10.0-RELEASE. We talked a little bit
about the bhyve(4) memory overcommit
work that
Neel has been doing for a quite long time, but we are hoping
that it will get into 10 as well. It gives much better
integration with management of guest memory, with the FreeBSD
Virtual Memory subsystem, so we can actually page guest memory
to swap. Some of the future directions for the
bhyve(4) work has also been discussed: we want to shift
away from the user-space boot loader, and use the BSD-licensed
UEFI code from Intel as a boot ROM, we want to have more Windows
guest support at some point, and getting the ability to suspend
and resume the guests, which eventually leads to adding support
for live migration.
ZFS
| Links |
Contact:
Martin
Matuška
<[email protected]>
Contact:
Matthew
Ahrens
<[email protected]>
For starting up, Justin Gibbs gave an overview of shingled media which is a new technology that is coming from the hardware vendors. We talked about some performance issues with that, came up with some simple ideas of how to make sure that everything can take advantage of this, or actually not to have bad performance when not deleting, just overwriting the data. We finally came to the conclusion that it is probably very hard to do better than that.
Then a status report of ZFS on other platforms besides FreeBSD and Illumos was given. On Linux, it basically works, it is being actively developed, it is in the kernel. On Mac OS X, it is quite immature, but there is a lot of work going on there. On Oracle Solaris, they are still working on ZFS but probably we will never see source code from them.
We talked about creating a common, cross-platform code repository for ZFS that all the platforms would pull code from. The idea here is that all the platforms available would get the platform-independent code from there verbatim, so getting changes into all platforms is much easier. This would not include things like the ZPL, which need to interface with each platform-specific VFS layer, but that would reduce the hackiness of the Solaris Porting Layer that is in FreeBSD and Linux while adding a little bit of porting layer to Illumos. We talked about how we should stage this work and we decided we definitely want to try to include the Linux developers from the beginning rather than doing just Illumos plus FreeBSD and then tacking on the Linux layer.
Next, we talked about test coverage and what tests are available. Spectra Logic has finished porting the STF test suite to FreeBSD, so we discussed how we can make them more widely available, and potentially getting them into the main source tree. Eventually, it will become part of the independent code repository but it may take a while to get there.
And then we also talked about zfsd, which is a substitute for FMA. This is a Solaris technology which deals with hot spares and device replacement, etc. So zfsd is a replacement for this tool on FreeBSD, implemented by Spectra Logic. With regard to this, we discussed some of the issues about getting it into the main tree, as they had done some subtle physical pathing that was not a hundred percent generic.
News Home | Status Home