Date: Sun, 1 Dec 2013 08:37:34 +0000 (UTC) From: Gabor Pali <pgj@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r43269 - head/en_US.ISO8859-1/htdocs/news/status Message-ID: <201312010837.rB18bYBD048864@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
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@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@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@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@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@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&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@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&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@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@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@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@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@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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201312010837.rB18bYBD048864>