Google Summer of Code 2013 - FreeBSD part I.

Google Summer of Code 2013 - FreeBSD part I.

Add Comment , ,
Hello guys, welcome to next part of my series about  Google Summer of Code 2013. You might wanna read previous ones: 

Google Summer of Code 2013 - Introduction
Google Summer of Code 2013 - NetBSD
Google Summer of Code 2013 - DragonFlyBSD

This time I will write about FreeBSD. 

What is FreeBSD?

FreeBSD is an advanced operating system for modern server, desktop, and embedded computer platforms. The FreeBSD Project began 20 years ago in 1993, but is based on the work at Berkeley CSRG with open source revision history going back 35 years to 1978.  Over those thirty years the code base has gone through continuous development, improvement, and optimization. The FreeBSD Project is a large, mature, and yet relatively tightly knit organization, developed and maintained by a large team of individuals. FreeBSD provides advanced networking, impressive security features, and world class performance and is used by some of the world's busiest web sites and most pervasive embedded networking and storage devices. 
There are currently over 300 developers with write access to the main revision control system, and hundreds more with access to our Perforce servers for experimental and third party development (this is also where our summer of code students have worked in previous years). We have an active mentoring program to bring all new developers into our community, not just those that we introduce to FreeBSD through the GSoC. There are hundreds of mailing lists, forums, blogs, IRC channels, and user groups all detailed on our main website.  FreeBSD offers a complete operating system in which students can work, not just a kernel or specific userland stack. This allows for interesting work that spans the userland/kernel boundary.
In addition to producing an operating system, FreeBSD has incubated the development of key pieces of infrastructure which are used by other open source projects including bsnmp, jemalloc, libarchive, OpenBSM, and OpenPAM.

 
So, this year, FreeBSD got 14 accepted projects. If you wondering what were other ideas they wanted to make via GSoC, head to Ideas webpage.  

Reports can be found at http://lists.freebsd.org/pipermail/soc-status/ mailing list. More details about projects at https://wiki.freebsd.org/SummerOfCode2013Projects.

1. Intelligent Download manager service for the Ports Collection 

Student: Ambarisha (ambarisha@freebsd.org)
Mentor: Xin Li (delphij@freebsd.org)

Ports collection, as of now, simply uses fetch(1) to download distfiles. There are a few drawback to this approach:
  • Duplicate downloads
  • Picking a mirror to download is a problem
  • Cannot cap download speed or number of connections
The requirements are clearly put down on the ideas page at https://wiki.freebsd.org/IdeasPage/IDMS. This project aims to fulfill those requirements.

Client:
The client will be a replacement of the current "fetch" program used by the ports collection. It will be used in the exact same way as fetch, but instead of actually fetching the files, it requests the Download Manager Service to download the files. It will be blocking on the service till the download is complete. It can frequently request the service for status updates.
Service:
The service assigns a "worker" thread to handle each request. If the request is for a file which is already being downloaded, the same download will be used to serve both requests. The service will also maintain a record of the download speeds from each mirror site. This record will be used to assign priority to the mirror site and the workers attempt to get a requested file from a site with higher priority. The service also updates any client with the status of the download upon request. 

2. XEN HVM Guest Support 

Student: Bei Guan
Mentor: Justin T. Gibbs
This project optimizes the I/O performance of FreeBSD as a Xen HVM DomU. It provides a USB front-end driver and a SCSI front-end driver to FreeBSD Xen HVM DomU. With these drivers, FreeBSD DomU can access the USB and SCSI devices provided by Xen instead of that emulated by QEMU. It improves the performance of reading and writing data to the devices. 

With the GENERIC config, FreeBSD Xen DomU accesses to the USB device by Qemu-dm USB passthrough supported by Xen. It needs to specify "usb=1" and "usbdevice='host:xxxx:yyyy'" in the DomU's config file. It doesn't require backed driver in Dom0 and front driver in DomU. However, this method is low performance. A USB front-end driver is part of the Xen para-virtualization mechanism. It forwards the USB I/O request from the DomU to the USB back-end driver in Dom0, and then the back-driver dispatches the request to the native USB device driver, which will access to the physical USB device and give the response to the USB back-end driver. At last, USB front-end driver can receive the result of the device request. This mechanism is known as PVUSB. PVUSB will replace the device emulated by Qemu and extremely improve the performance of USB I/O access. 

The SCSI device access in FreeBSD DomU is supported through device emulated by QEMU currently. The project is very similar to the USB front-end driver. The para-virtualized SCSI driver is also known as PVSCSI. It can be used by a Xen PV or HVM guest to passthrough the SCSI device, such as tape drives, scanners, printers and CD drives. PVSCSI works like the PVUSB. The front-end driver forwards the SCSI device I/O request from the DomU to SCSI back-end driver in Dom0. And then, it receives the result from the SCSI device forwarded by back-end driver 

We break the problem into smaller parts that we will solved.
  1. Define the data structures and function interfaces of USB/SCSI front-end driver.
  2. Provide a USB/SCSI front-end driver to FreeBSD DomU configured with XENHVM to replace the emulated device provided by Xen Qemu.
  3. Provide some test cases to show the USB/SCSI front-end driver works well. Provide some data to show the performance improvement for FreeBSD accessing to the USB devices and SCSI devices, such as reading and writing operations. 

The Code


3. net80211 rate control API - 802.11n extensions

Student: Chenchong Qin (<ccqin AT SPAMFREE freebsd DOT org>)
Mentor: Adrian Chadd (<adrian AT SPAMFREE freebsd DOT org>)

There is a simplistic rate control API in net80211 of FreeBSD, which lack the support of 802.11n features. 802.11n brought a 10x maximum net data rate compared to its predecessor, but, unfortunately, the hard-won rate up can be easily wasted if rate control hasn't been properly performed. This project will extend the net80211 rate control API of FreeBSD to be 802.11n aware and be able to support multiple rate attempts. With the extended API, wireless throughput can be further imrpoved.

An 802.11n features aware net80211 rate control API.
A summary of the feature improvements are listed below:
  1. Multiple Rate Attempts Support: The current rate control API of net80211 in FreeBSD is quite straightforward. The way of performing rate control is just selecting the “best” rate found by rate adaptation algorithms. Rather than just selecting the “best” rate, the rate control API should be able to do some real “control” works. It should be able to support multiple rate attempts which ath(4) hardware support.
  2. 802.11n Features Support: The rate control API should be extended to support 802.11n features including MCS rates, 20/40MHz wide channels, short-gi, stbc, ldpc. 802.11n APs and STAs need to negotiate capabilities like the type of RF modulation, coding rate and channel width. They also must agree upon the guard interval and number of spatial streams to be used. The 802.11n standard defines Modulation and Coding Scheme (MCS) a simple integer assigned to index 77 possible permutations of the factors that determine data rate. The standard also added support for short guard interval (short-gi), which provides an 11% increase in data rate. The rate control API of net80211 in FreeBSD should support these features to perform better rate control operations in 802.11n environment.
  3. Statistics API: A interface for exposing the global, per-vap and per-device rate control statistics should be added to the rate control API of net80211 in FreeBSD. This is pretty a useful feature for developers, academic researchers and, of course, end-users.
  4. 802.11n Aggregation Support: Frame aggregation is a feature of 802.11n that increases throughput by sending two or more data frames in a single transmission. Instead of having one frame be transmitted and received at a time, with A-MPDU, multiple subframes can be aggregated for one transmission and sender can be told of which subframes were successfully received. The current rate control API of net80211 in FreeBSD only works well for non-aggregate frames as it would be called each for a rate lookup and a single frame completion. With 802.11n aggregation, the rate control API should be extended to perform a single rate lookup for an aggregate, which will consist of multiple frames. 

The Code
Code is here


4. Port data compression services and video codecs to Capsicum

Student: Daniel Peyrolón (dpl@freebsd.org)
Mentor: Brooks Davis (brooks@freebsd.org)

This project will port the following to Capsicum:
  • bzip2
  • xz
  • zip
  • libavcodec

The code
svn rep
 

5. Qt and GTK+ Front Ends for PKGNG 

Student: JustinMuniz <jmuniz AT SPAMFREE FreeBSD DOT com>
Mentor: EitanAdler <lists AT SPAMFREE eitanadler DOT com>
This project aims to actualize a GUI for advanced binary package management in FreeBSD. The recently released PKGNG utility is the foundation for this project; PackageKit will provide a friendly and intuitive user interface. The package management interface will be easy to use and understand for new FreeBSD users, while offering powerful tools to novice and advanced users. Features of this approach include automatic updates, desktop notifications, and package management within jails.

The code

For help using the code in this repository, please read README.
Student: KonradWitaszczyk (def@FreeBSD.org)
Mentor: GlebKurtsou (gleb@FreeBSD.org)

Kernel dump may contain a backtrace of function calls, information about processes or even device data. These information should not be seen by a person trying to attack our OS because it might help to hack it. The main goal of the project is to implement encrypted crash dumps. It means that a user will have to decrypt a dump before analysing it. Crash dumps will be encrypted with an one-time AES key which will be shared with a user using an asymmetric key encryption.

In order to finish this feature it is required to modify crash dump routines, savecore(8) and crashinfo(8). Our solution will use a random symmetric key to encrypt data with AES using XTS mode which will be encrypted with an asymmetric key chosen by a user. We will start with constant keys to implement encryption and then we will make it more user-friendly. After reboot caused by a panic, savecore(8) will copy the dump and its key to dumpdir and make it able to decrypt with PEFS. 

The Code
Modified FreeBSD-HEAD: https://svnweb.freebsd.org/socsvn/soc2013/def/crashdump-head/
 
 
To be continued ;] 
SHARE

JH

software developer - guitar player - poetry lover

    Blogger Comment
    Facebook Comment

0 comments:

Post a Comment

Subscribe to: Post Comments ( Atom )