svn commit: r43269 - head/en_US.ISO8859-1/htdocs/news/status
Gabor Pali
pgj at FreeBSD.org
Sun Dec 1 08:37:35 UTC 2013
Author: pgj
Date: Sun Dec 1 08:37:34 2013
New Revision: 43269
URL: http://svnweb.freebsd.org/changeset/doc/43269
Log:
- Import an initial version for the EuroBSDcon 2013 Developer Summit Special
Report
Reviewed by: bcr, erwin, grehan, hselasky, Matthew Ahrens
Added:
head/en_US.ISO8859-1/htdocs/news/status/report-2013-09-devsummit.xml (contents, props changed)
Modified:
head/en_US.ISO8859-1/htdocs/news/status/Makefile
Modified: head/en_US.ISO8859-1/htdocs/news/status/Makefile
==============================================================================
--- head/en_US.ISO8859-1/htdocs/news/status/Makefile Sat Nov 30 18:31:04 2013 (r43268)
+++ head/en_US.ISO8859-1/htdocs/news/status/Makefile Sun Dec 1 08:37:34 2013 (r43269)
@@ -62,6 +62,7 @@ XMLDOCS+= report-2013-01-2013-03
XMLDOCS+= report-2013-04-2013-06
XMLDOCS+= report-2013-05-devsummit
XMLDOCS+= report-2013-07-2013-09
+XMLDOCS+= report-2013-09-devsummit
XSLT.DEFAULT= report.xsl
Added: head/en_US.ISO8859-1/htdocs/news/status/report-2013-09-devsummit.xml
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2013-09-devsummit.xml Sun Dec 1 08:37:34 2013 (r43269)
@@ -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 at FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&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 at FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&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; 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 at FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&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 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 at FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&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; 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 at FreeBSD.org</email>
+ </person>
+
+ <person>
+ <name>
+ <given>Matthew</given>
+ <common>Ahrens</common>
+ </name>
+ <email>mahrens at 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 at FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&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>></tt> instead of <tt>>=</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; 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 at FreeBSD.org</email>
+ </person>
+
+ <person>
+ <name>
+ <given>Brooks</given>
+ <common>Davis</common>
+ </name>
+ <email>brooks at FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&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; 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; 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; 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
+ — 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 — 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 at FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&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; 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 — 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 at FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&target=20130928-eurobsdcon-dns-summary.pdf">Summary</url>
+ </links>
+
+ <body>
+ <p>&os; 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; 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; 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 at FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&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 at FreeBSD.org</email>
+ </person>
+ </contact>
+
+ <links>
+ <url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&target=DevSummitUSB2013Status.pdf">Summary</url>
+ <url href="https://wiki.freebsd.org/201309DevSummit?action=AttachFile&do=get&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 at 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>
More information about the svn-doc-head
mailing list