os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

- Import an initial version for the EuroBSDcon 2013 Developer Summit Special

Browse source 
Report

Reviewed by:	bcr, erwin, grehan, hselasky, Matthew Ahrens
This commit is contained in:
Gabor Pali 2013-12-01 08:37:34 +00:00
parent 78052a6d4d
commit 5822b23d1c
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=43269
2 changed files with 916 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
en_US.ISO8859-1/htdocs/news/status/Makefile
View file

@ -62,6 +62,7 @@ XMLDOCS+= report-2013-01-2013-03
XMLDOCS+= report-2013-04-2013-06 XMLDOCS+= report-2013-04-2013-06
XMLDOCS+= report-2013-05-devsummit XMLDOCS+= report-2013-05-devsummit
XMLDOCS+= report-2013-07-2013-09 XMLDOCS+= report-2013-07-2013-09
XMLDOCS+= report-2013-09-devsummit
XSLT.DEFAULT= report.xsl XSLT.DEFAULT= report.xsl

915
en_US.ISO8859-1/htdocs/news/status/report-2013-09-devsummit.xml Normal file
View file

@ -0,0 +1,915 @@
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for Status
Report//EN" "http://www.FreeBSD.org/XML/share/xml/statusreport.dtd">
<!-- $FreeBSD$ -->
<report>
<date>
<month>September</month>
<year>2013</year>
</date>
<section>
<title>EuroBSDcon 2013 Developer Summit Special Status Report</title>
<p>This special status report contains a summary of the discussions
from the various working groups at the EuroBSDcon 2013 Developer
Summit. The &os; Project organizes developer summits at various
events, typically at the major BSD conferences, so that developers
can meet and discuss matters in person.</p>
</section>
<project>
<title>Toolchain and Build Systems</title>
<contact>
<person>
<name>
<given>Brooks</given>
<common>Davis</common>
</name>
<email>brooks@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&amp;do=get&amp;target=toolchain-and-build-eurobsdcon2013.pdf">Summary</url>
<url href="https://wiki.freebsd.org/201309DevSummit/ToolchainAndBuild">Notes</url>
<url href="https://wiki.freebsd.org/201308DevSummit/ToolchainAndBuild">Cambridge notes</url>
<url href="https://wiki.freebsd.org/GPLinBase">Roadmap</url>
</links>
<body>
<p>The discussions on toolchains and build systems happened in
Malta has 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.</p>
<p>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.</p>
<p>In the context of replacing GCC we discussed David Chisnall's
plan to stop building GCC and <tt>libstdc++</tt> 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.</p>
<p>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
<tt>freebsd-update(8)</tt> does including upgrades and detecting
changed files in a more operating-friendly way. Using
<tt>pkg(8)</tt> as a replacement for <tt>freebsd-update(8)</tt>
is not a general solution yet as package signing and delta
support is required to make it viable.</p>
<p>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.</p>
<p>About half the meeting was consumed by a detailed walkthrough
of the <tt>GPLinBase</tt> wiki page (see links). A number of
areas need modest amounts of work and <tt>binutils</tt>
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.</p>
<p>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 <tt>-B</tt> and possibly
<tt>--sysroot</tt> between Clang and GCC. Further discussions
of external toolchain support occurred in the Embedded
session.</p>
</body>
</project>
<project>
<title>Documentation</title>
<contact>
<person>
<name>
<given>Benedict</given>
<common>Reuschling</common>
</name>
<email>bcr@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&amp;do=get&amp;target=DocWGSummaryReport.pdf">Summary</url>
</links>
<body>
<p>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.</p>
<p>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 &os; Forums,
while they have established themselves as another support option
for users.</p>
<p>Then the representatives of the &os; 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 &os; Foundation website look similar to the &os;
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.</p>
<p>Another thing that we have talked about was the on-going print
edition work of the &os; 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 a 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.</p>
<p>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.</p>
<p>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 <tt>doc</tt> tree, like the ones who are
still reflecting &os;&nbsp;5.x or so. In summary, the main
objective is to have a system that helps 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.</p>
</body>
</project>
<project>
<title>Desktop</title>
<contact>
<person>
<name>
<given>Kris</given>
<common>Moore</common>
</name>
<email>kmoore@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&amp;do=get&amp;target=DesktopWG-Summary.pdf">Summary</url>
</links>
<body>
<p>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 <tt>9.2-RELEASE</tt> are in
progress, and future builds based on <tt>10-STABLE</tt> are
coming soon. The plan there is to track the <tt>10-STABLE</tt>
branch until it becomes <tt>11-STABLE</tt>. Kris also described
the <q>rolling release</q> model they have been switched to.
This approach leverages <tt>freebsd-update(8)</tt> to provide
rolling updates for the base system (that is, the kernel and the
userland utilities) and in parallel with that, <tt>pkg(8)</tt>
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
authention.</p>
<p>Next, the current in-progress items were reported and
discussed. The <tt>sysutils/pcbsd-utils</tt> and
<tt>sysutils/pcbsd-utils-qt4</tt> 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 been also working on a
<q>life-preserver</q> ZFS command-line and GUI utility, which is
still in heavy development. The purpose of this tools to
leverage ZFS for snapshot and replication functionality as a
backup solution.</p>
<p>Finally, the plans for PC-BSD&nbsp;10 was summarized. The PBI
package format that PC-BSD employs in now under revision and
will be updated to use <tt>pkg(8)</tt> repository to build PBIs,
provide better integration for server PBIs. As part of this
effort, it will be also investigated whether it is possible to
run PBIs without actual installation. <tt>pc-sysinstall</tt>
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 <tt>pc-sysinstall</tt> backend.</p>
</body>
</project>
<project>
<title>Virtualization</title>
<contact>
<person>
<name>
<given>Peter</given>
<common>Grehan</common>
</name>
<email>grehan@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&amp;do=get&amp;target=eurobsdcon_summary.pdf">Summary</url>
<url href="https://wiki.freebsd.org/201309DevSummit/Virtualization">Notes</url>
</links>
<body>
<p>In the virtualization working group, Peter Grehan gave a usual
status report. In &os;&nbsp;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
<tt>bhyve(4)</tt> into 10.0-RELEASE. We talked about little bit
about <tt>bhyve(4)</tt> <q>memory overcommit</q> 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 &os; Virtual Memory
subsystem, so we can actually page guest memory to swap. Some
of the future directions for the <tt>bhyve(4)</tt> work has been
also 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 adding support for live migration.</p>
</body>
</project>
<project>
<title>ZFS</title>
<contact>
<person>
<name>
<given>Martin</given>
<common>Matuška</common>
</name>
<email>mm@FreeBSD.org</email>
</person>
<person>
<name>
<given>Matthew</given>
<common>Ahrens</common>
</name>
<email>mahrens@delphix.com</email>
</person>
</contact>
<links/>
<body>
<p>For starting up, Justin Gibbs gave an overview of shingled media
which is a new hardware 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 get
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.</p>
<p>Then a status report of ZFS on other platforms besides &os; 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.</p>
<p>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 hackyness
of the Solaris Porting Layer that are in &os; and in 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 an Illumos plus &os; and then tackling on
the Linux layer.</p>
<p>Next, we talked about test coverage and what tests are
available. Spectra Logic has finished porting the STF test suite
to &os;, 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.</p>
<p>And then we also talked about <tt>zfsd</tt>, which is a
substitute for FMA. This is a Solaris technology which deals
with hot spares and device replacement, etc. So <tt>zfsd</tt>
is a replacement for this tool on &os;, 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 hundred percent
generic.</p>
</body>
</project>
<project>
<title>Security</title>
<contact>
<person>
<name>
<given>Dag-Erling</given>
<common>Smørgrav</common>
</name>
<email>des@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&amp;do=get&amp;target=201309+DevSummit+Security+Report.pdf">Summary</url>
<url href="https://wiki.freebsd.org/201309DevSummit/Security">Notes</url>
</links>
<body>
<p>In the security working group, we had four items in the agenda.
First of all, we started with the current state of
<tt>/dev/random</tt>. There were a number of known entropy
harvesting bugs that have been fixed, for example feeding a lot
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 <tt>/dev/random</tt>. 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
<tt>initrandom</tt> script that feeds mostly static data into
<tt>/dev/random</tt> and pretends that is actually entropy,
while 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 <tt>/dev/random</tt> and it turns
out that one can get about 4 good bits of entropy from each
device. Also, we should have the installer to fill up the
<tt>/entropy</tt> 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 example, we discussed
having the installer generate SSH keys. But 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.t The device
attach patch helps with that.</p>
<p>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
<tt>/etc/pkg/fingerprints</tt>. If we need to revoke a key, or
distribute a new key, we will just issue a new &os; Security
Advisory (which should be done anyway), and will have
<tt>freebsd-update(8)</tt> to distribute an update that moves
the key from the <tt>trusted</tt> directory to the
<tt>revoked</tt> directory, and adds the new key to the
<tt>trusted</tt> directory. When launched, <tt>pkg(8)</tt>
looks into those directories, loads all the keys it founds, and
will accept a packages if it is signed by at least one good key
and no revoked keys.</p>
<p>Package signing was followed by mitigation by Sofian Brabez.
He has stackgap optimization and <tt>mmap()</tt> 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. <tt>mmap()</tt>
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 of how some ports build.
<tt>libc</tt> is now a linker script and not just a <tt>.so</tt>
file, therefore the linker will always know how to handle this.
<tt>ldbase</tt> randomization was also discussed, but it has not
been implemented. It randomizes where the libraries are loaded
by the run-time linker.</p>
<p>The final item on the agenda was VuXML and <tt>portaudit</tt>. We
have a number of shortcomings with VuXML. One of them is that the
<tt>portaudit</tt> 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 <tt>&gt;</tt> instead of <tt>&gt;=</tt>.
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, the kernel
patch level does not necessarily reflect the patch level of the
userland, because <tt>freebsd-update(8)</tt> 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 <tt>pkg(8)</tt> packages. CPEs published by
NIST can be simply pushed directly to VuXML and we do not have
to the matching ourselves any more. The specification of CPE
includes a matching algorithm and shipped with a reference
implementation. &os;&nbsp;10 is going to install a script under
<tt>/libexec</tt> that prints the userland patch level, and
<tt>freebsd-update(8)</tt> will update that script so it will be
possible to verify the userland patch level as well.</p>
</body>
</project>
<project>
<title>Embedded Platforms</title>
<contact>
<person>
<name>
<given>Warner</given>
<common>Losh</common>
</name>
<email>imp@FreeBSD.org</email>
</person>
<person>
<name>
<given>Brooks</given>
<common>Davis</common>
</name>
<email>brooks@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&amp;do=get&amp;target=Embedded-devsummit-201309.pdf">Summary</url>
<url href="https://wiki.freebsd.org/201309DevSummit/Embedded">Notes</url>
<url href="https://wiki.freebsd.org/201308DevSummit/Embedded">Cambridge notes</url>
</links>
<body>
<p>The discussion on embedded platforms has 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.</p>
<p>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 stabalization 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 (sson 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 <tt>freebsd-update(8)</tt> 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.</p>
<p>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.</p>
<p>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 &os;&nbsp;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 &os;&nbsp;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 the given
platform.</p>
<p>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).</p>
<p>We talked a lot about what to do around the ARM port in
&os;&nbsp;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 <tt>armv6</tt> platform
&mdash; currently there is a number technical roadblocks to
that. We want to keep the <tt>armv4</tt> and <tt>armv5</tt>
support in 11 until there is some particular reason not do that.
One of the biggest tasks probably, since we are moving to Clang,
would be the external toolchain item. Besides that, the
<tt>armv6</tt> 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 Raspberri 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 <tt>freebsd-update(8)</tt>. It was also
briefly mentioned that there is no good GPU support on ARM right
now, and that is on the &os; 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 &mdash; there is a
number of challenges in this case.</p>
<p>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
<q>domains</q> from the device tree, and they need to be
threated as such. Also, GPIO and pinmux is inconsistent between
the different releases, we need to fix that. We also talked
about Arm64, where there is lot of things to do. The key though
is find out (with the assistance of the &os; 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. We have concluded, together
with the Semihalf people and the ARM representative, Andrew
Wafaa, at the summit, after investigating Arm64, that it 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.</p>
</body>
</project>
<project>
<title>Ports and Packages</title>
<contact>
<person>
<name>
<given>Erwin</given>
<common>Lansing</common>
</name>
<email>erwin@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&amp;do=get&amp;target=20130928-eurobsdcon-ports-summary.pdf">Summary</url>
<url href="https://wiki.freebsd.org/201309DevSummit/Ports">Notes</url>
</links>
<body>
<p>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 <tt>--delay-update</tt> flag for
<tt>rsync(1)</tt> 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 few interesting ideas that we
could pick and use for the &os; package distribution network.
This was then followed by a talk by Jeremy Le Hen, who talked
about stack protection (SSP). It is going to be enabled by
default in &os;&nbsp;10.x on amd64 and i386 platforms, but can
be turned off by the <tt>SSP_UNSAFE</tt> knob. On the contrary,
it is not enabled by default on 9.x, but it can be turned on by
the other knob, <tt>WITH_SSP_PORT</tt>. This should work on
amd64, and it has no effect on i386.</p>
<p>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
<tt>NEED_ROOT</tt> 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, catches broken plists, helps
to get rid of the special <tt>post-install</tt> scripts. It
lies the foundation for some new features we want to add in the
future, for example implementing sub-packages. Having
sub-packages enables to build packages once and put 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 &mdash; however, at some point, we might say that
ports not converted to support staging will be removed.
Actually, this would help us to find out which ports in the tree
are not used any more.</p>
<p>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 to have many
things to happen before we could proceed, such as move away from
CVS, introduce new-style binary packages, deploy new build
clusters. We have finally got them all, and we can actually do
it now with the <tt>pkg-test</tt> setup. So, we are hoping to
start with the first quarterly release in early November.</p>
<p>We had a long discussion about removing support for old-style binary
packages, now we have <tt>pkg(8)</tt>. Staying compatible with
<tt>pkg_install(1)</tt> 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
<tt>pkg(8)</tt> 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 <tt>pkg(8)</tt>. So, at BSDCan next year, we can
hopefully celebrate the switch from <tt>pkg_install(1)</tt>.</p>
<p>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 <tt>LATEST_LINK</tt> to work this
behavior around. We should educate people to make better use of
<tt>PKGNAMESUFFIX</tt> 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.
<tt>PKGNAME</tt> must be unique across categories, so when one
uses <tt>pkg-add(8)</tt>, 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.</p>
</body>
</project>
<project>
<title>DNS</title>
<contact>
<person>
<name>
<given>Erwin</given>
<common>Lansing</common>
</name>
<email>erwin@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&amp;do=get&amp;target=20130928-eurobsdcon-dns-summary.pdf">Summary</url>
</links>
<body>
<p>&os;&nbsp;10 is not going to have BIND any more, it is going to
be based on <tt>unbound(8)</tt> and LDNS, both have been
imported into the base system, along with a small
<tt>host(1)</tt> replacement. LDNS also comes with
<tt>drill(1)</tt> that needs a simple wrapper to make it
compatible with the <tt>dig(1)</tt> command-line interface.
OpenSSH can use LDNS for checking SSH fingerprints which also
implies that DNSSEC validation is enabled by default. Note that
<tt>unbound(8)</tt> 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.</p>
<p>For the next major version, &os;&nbsp;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 has been
many proposals for that, like the get-api from Hoffman, or
draft-hayatnagarkar-dns-ext-validator-api for <tt>libval</tt>,
but it is currently being standardized by members of IETF. What
we want to do is to contact those people and make sure that
&os;&nbsp;11 will become a standard reference
implementation.</p>
</body>
</project>
<project>
<title>Vendor Discussions</title>
<contact>
<person>
<name>
<given>Erwin</given>
<common>Lansing</common>
</name>
<email>erwin@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&amp;do=get&amp;target=20130928-eurobsdcon-vendor-summary.pdf">Summary</url>
</links>
<body>
<p>First, Justin Gibbs, on behalf of the &os; Foundation, gave a
status update. A major change that previously we had only a
single part-time employee, who was 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, e.g. the Release
Engineering Team and the Security Team. We also employed Glen
Barber as a system administrator who is working with the &os;
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.</p>
<p>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 &os; but the company did
not allow him to do that as they could not get a commercial
support for &os;, so he started his own company solely for this
purpose, which for example, includes hardware certification.</p>
<p>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 the
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 &os; 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.</p>
</body>
</project>
<project>
<title>USB</title>
<contact>
<person>
<name>
<given>Hans-Petter</given>
<common>Selasky</common>
</name>
<email>hselasky@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&amp;do=get&amp;target=DevSummitUSB2013Status.pdf">Summary</url>
<url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&amp;do=get&amp;target=DevSummitUSB2013.pdf">Notes</url>
</links>
<body>
<p>In the USB working group, Hans-Petter Selasky summarized what
happened to &os;'s USB stack during the last one 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 &os; 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 <tt>webcamd(8)</tt> 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.</p>
<p>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.</p>
</body>
</project>
<project>
<title>Developer Summit Track</title>
<contact>
<person>
<name>
<given>Gábor</given>
<common>Páli</common>
</name>
<email>pgj@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://goo.gl/2EF30C">Playlist of the talks</url>
</links>
<body>
<p>Since 2011, the &os; 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 &os; development process and how to improve
it, talk about how their company uses &os;, or coordinate
activities. One can also catch reports from the Google Summer
of Code students at the European instances.</p>
<p>At EuroBSDcon 2013 we had talks in 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 &os;-based network simulation environment, finally
porting Mirage, an operating system written in the OCaml
functional language, to &os;. The playlist of the talk
recordings (audio with slides and demonstrations) can be found
above at the entry's URL section.</p>
</body>
</project>
</report>