I arrived in Maarssen on the 5th of October and met up with fellow developers for drinks at the hotel and then dinner.
On the 6th, we headed to the conference site and commenced with the developers summit. After an opening session, we broke up into working groups. For the first session, I attended the ports session. I lead a short discussion on the ports impact of our migration to Clang/LLVM as the base tool chain. The general conclusion was that we need to add support for switching the default ports compiler (a project which is well underway), as well as the ability to specify a restricted set of acceptable compilers for a given port. There seemed to be solid support for allowing the default to be clang for FreeBSD 10 builds on architectures where we make it the base compiler.
After lunch, I lead a session on our toolchain work. I outlined our current status to the group. The status report was followed up by a discussion of the remaining requirements to produce a GPL-free base system. Those items include:
- an LLDB port
- libgcc replacement on some architectures (at least MIPS and sparc64)
- libgcc*.so
- FDT tools
- unwinding library
- GDB server
- as(1) wrapper (maybe?)
- 16-bit ASM support (at least on x86)
- libdwarf
Of the pieces required for a GPL-free base, the largest component remaining is a linker. Because linkers have quite a bit of scope, we spent most of the remaining time brainstorming requirements for a BSD licensed linker. Those requirements included:
- linker scripts (or equivalent)
- LTO framework
- Link time optimization against IR or machine code
- Incremental linking
- Support for IR in ELF
- GNU ld compatibility
- IR processing by plugin
- Limited non-ELF support (for boot blocks, etc)
- Alternative hash table support
- Crunching support
- Be fast
- Native cross-architecture support
- Multipass lookup
- Unit tests
- Coded to LLVM standards (to allow inclusion in LLVM)
- linker is a library
- C and C++ support
- Architecture support: i386, x86_64, ARM, PPC(64), MIPS(64), PiNaCl
- Possible architecture support: sparc64
Friday the 7th commenced with an opening session followed immediately by working group reports. I reported on the toolchain session and most other session leaders reported on their sessions. That was followed by a discussion of options for using Git to track FreeBSD. At the end we concluded that we definitely need a git.freebsd.org to provide officially "blessed" git trees, but we left some details unresolved such as the exact scope of the git trees. This discussion was followed by a set of presentations by Chris Buechler of pfSense, Jeroen van Nieuwenhuizen of Snow, Robert Watson of the Cambridge Computer Laboratory and Yvan Vanhullebus of NETASQ on their use (or non-use in the case of Snow's clients) of FreeBSD. After these presentations we broke for lunch.
When we reconvened after lunch we started with a discussion of virtualization on FreeBSD. In a number of key ways FreeBSD was late to the virtualization game, but it looks like we're catching up. Between the addition of BHyVe and an upcoming Xen Dom0 implementation, we will soon be well positioned to host guest VMs on FreeBSD and our support for running as a guest seems to be improving steadily. We're still behind in some senses, but given the remarkably poor reality that is accepted as the state of the art, it seems like we have a chance to pull ahead in areas of management if we invest some effort.
The virtualization session was followed by a session for FreeBSD 10.0 brainstorming. As usual for such a session, many ideas were generated. If even half of them are completed, I think we'll have a fantastic 10.0 release.
Following the success of the dev summit track introduced at BSDCan this spring, Saturday contained such a track along side the conference. I attended several of these talks and gave a presentation on our participation in the 2011 edition of the Google Summer of Code. We had 13 successful projects and have already gained two comitters as a result of this year's projects, with a couple more expected in the next few months.
No comments:
Post a Comment