All persons need to be asked if they are working on it or want to work on it (or maybe want some help). Mentors need to be asked if they are still interested and if they know if someone else is working on it already. Mentor should also be asked to improve the entry. Existing entries need to be reviewed if they are similar and should be enhanced with some stuff from the proposal (entries on the SoC page need to be examined too). --------------------------- PMC GUI tool (SoC proposal from Mathieu Prevot and Sanel Zukan ) Hwpmc (Hardware Performance Monitoring Counter) is driver which virtualizes the hardware performance monitoring facilities in modern CPUs and provides support for using these facilities from user level processes (from man). Preciselly, hwpmc is kerner driver which is designed to be a general purpose interface to the CPU's PMC resources. By Mathieu: ---snip--- The project consists in creating a graphical user interface (GUI) analysis tool. It will be based on the performance monitoring counters framework pmc(3) and pmclog(3), using in-cpu measurement counters. The PMC GUI will allow a visual detection of performance bottlenecks in the execution of a program. Impact Management / welcome screen. In this place, the user associates PMCs (measurements) and processes. A set of allowed measurements i.e. according to the CPU - will be proposed to the user. Target processes can be selected by mouse. Display/monitoring. In this place, the user can see in realtime what is happening. Profiling will concern selected processes, threads, and children or descendant processes. Spots/rectangles will correspond to a code segment. There will be a time view of the spots, with 1-2-3D graphes and color codes. ---snip--- By Sanel: ---snip--- Benefits to the FreeBSD Community: Because this tool is introduced in FreeBSD 6.0 version, its popularity can be more gained in FreeBSD community, with simple (for first time user) but powerfull (for advanced users) and usable GUI. It can also show others (for example Linux community) a good alternative for oprofile/perfmon/syscl tools (especially their more often used GUI frontends). All requested features are planned to be provided: system-wide and process-specific analyses, visual view of hotspots in executables and shared libraries and ability to view annotated source or machine code listing. Deliverables: - Provide ability of attaching to selected processes or threads - Display a graph for the progression of hotspots in a process or in the kernel - Display source code (if can be located) or disassembly listing (if source code can't be located) in apropriate window - Display a graph for possible tlb/cache miss summarizing collected data over some time - Try to build small user community during development time ---snip--- mentor: jkoshy? not in FreeBSD CVS, but in ports ------------------------------ libnetstat (SoC proposal from Francesco Fusco ) The project I'm going to propose is an abstraction monitoring library called libnetstat deeply inspired by libmemstat written by Robert Watson. Libnetstat will provide an abstraction layer that can be used by applications to get information about FreeBSD networking subsystem. Libnetstat will takes care about reading and understanding FreeBSD kernel internal data structures and will provide a stable API to get the interpreted information from the kernel. Monitoring applications will benefits from the library because the library hides all the complexity and the details of kernel version dependent information. mentor: rwatson? --------------------------- FreeBSD GEOM 'safety net' IO logging utility (glog) (SoC proposal from Sonja Milicic ) Project title: -------------- FreeBSD GEOM "safety net" IO logging utility (glog) Author: ------- Sonja Milicic Mentor: -------- Synopsis: --------- A userland utility implemented using GEOM gate (ggate) to allow copy-on-write style logging of I/O requests. Project Description: -------------------- There are several actions, for example file system debugging or repair, which could be performed more easily and with less risk if there was a "safety net" on a device. This project aims to implement a virtual storage device managed by a userland daemon which attaches to a physical device and performs copy-on-write logging of write requests to the device in a specified file. This virtual device will for all intents and purposes look like the original physical device, only write requests will not be passed to the device but redirected into the log file. This log file can later be analysed, replayed or discarded (deleted). The number of such log files will not be limited, so several possible operations can be performed and their result compared before commiting one of them to physical device storage. This work will be licensed under the BSD license. Technical Details: ------------------ The basic idea is to create a daemon that uses the ggate module / framework to create (provide) a GEOM device, and which will attach to an existing GEOM device. Write requests to the created virtual device will be redirected either to the original device or to the log file. This project is similar to the "gjournal" project done last year (also as a Summer of Code project), but has the following benefits over it: * is a much simpler scheme, that doesn't include complex data journaling * doesn't try to do two things at once * uses ordinary files for data log, which means it's not tied to a (fixed) particular device size (files can grow), doesn't require setting up a separate device or partition for its operation, and can allow creation of multiple (different) log files for one original device/provider * can use tricks such as data compression because it's not restricted to sector-granularity in the log file * its log files can be processed by ordinary third-party applications * is easier to set up in a hurry (such as when a file system gets corrupted) Benefits for FreeBSD: --------------------- Copy-on-write journaling of storage devices/data received much attention during the development of gjournal project, but gjournal proved to be rather inflexible for simple COW usage because of its requirement for using raw GEOM devices for the journal. A user space utility will be easier to set up and use and allow more flexibility in operation. pjd@ prefers to do it in the kernel instead of the userland to be more reliable. ------------------------------ BSD licensed API compatible version of GNU readline (SoC proposal from Dylan Leigh ) Write a cleanroom implementation of the GNU Readline and History libraries (see http://cnswww.cns.cwru.edu/~chet/readline/rltop.html) which is API compatible, released under a BSD licence. mentor: jkh? he would import it into OS X too. --------------------------------- 'Enhancements to the Integrated SNMP Monitoring in the FreeBSD Operating System', part of the 'Fully Integrated SNMP Monitoring' idea for the FreeBSD project. (SoC proposal from Ricardo Nabinger Sanchez ) [Project Title] "Enhancements to the Integrated SNMP Monitoring in the FreeBSD Operating System", part of the "Fully Integrated SNMP Monitoring" idea for the FreeBSD project. [Synopsis] Implement a module for the BSNMP daemon which provides information as defined in the EtherLike-MIB (RFC-3635), and also design and implement an extension to the HOST-RESOURCES-MIB (RFC-1540 and RFC-2790). Both enhancements will be implemented as modules to the BSNMP daemon, in the C language. [Benefits to the FreeBSD Community] Although there are others implementations of SNMP daemons, BSNMP development focuses, even unintentionally, the FreeBSD Operating System. Thus, extensions and improvements to it will surely have a positive impact mainly for system and network administrators managing FreeBSD hosts. Interoperability with others implementations is ensured by the SNMP protocol. EtherLike-MIB provides important information about the underlying network infrastructure to system and network administrators. The proposed extension to the HOST-RESOURCE-MIB, combined with EtherLike-MIB, enable these professionals to better monitor and manage their network environment. SNMP is very well suited for remote management, and also an open standard published by the IETF. [Deliverables] * Functional implementation for the EtherLike-MIB (IETF RFC 3635), in the C Language, as a module for the BSNMP daemon. Must compile and run under a FreeBSD 6-STABLE and 7-CURRENT. * Creation and implementation of an additional MIB which will extend and provide additional data when compared to current HOST-RESOURCES-MIB standard. Also, must compile and run under FreeBSD 6-STABLE and 7-CURRENT. [Project Details] Extensions to the BSNMP daemon are in form of modules, which implement certain functionalities, using the C language. These modules are accessed when queries ask for data they provide, having them to poll the operating system on their behalf. The EtherLike-MIB is a proposed standard, approved by the IETF as RFC-3635. Its implementation must follow the guidelines described in the RFC. The data provided by this module will be polled from the respective interface driver (e.g.: xl driver for a 3com NIC) and returned to the querier. The extension to the HOST-RESOURCES-MIB require two steps: first the design and creation of a MIB, named DISKSTORAGE-MIB, that will describe what information will be available; second is the implementation itself of this MIB. Although portions of the information may be obtained through the HOST-RESOURCES-MIB, this MIB will provide much more detailed and complete information. This includes informative data equivalent as provided by lsvfs(1), mount(8), nfsstat(1), and dumpfs(8) commands. [Relevant Publications] * "A SNMP-Based Platform for Distributed Stateful Intrusion Detection in Enterprise Networks", in IEEE Journal on Selected Areas in Communications. http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1514526 * "On the Development of IETF-based Network Monitoring Probes for High Speed Networks", in III IEEE Latin American Network Operations and Management Symposium. http://mutuca.metropoa.tche.br/PDF/2003_lanoms_10.pdf mentor: harti? check if the current SoC project is similar! -------------------------------- A mechanism for centrally installing FreeBSD on several networked computers. (SoC proposal from Cian Hughes ) * Project Title: A mechanism for centrally installing FreeBSD on several networked computers. -This idea is an extension of the "Bundled PXE Installer" Example Preposal Idea on freebsd.org. As part of my research in preparing this preposal I have produced a prototype installer that meets those requirements and I wish to build on that idea. * Possible Mentor: Murray Stokely said he might be able to co-mentor, I'd be happy with any mentor. * Benefits to the FreeBSD Community; this project would: -Make it easier to install FreeBSD on several computers at once, especially if their desired configuration is the same. -Ease of Installation is a major factor when choosing on OS, as rapid deployment is often a reqirement. -Allow installation on computers without CDROM, Video-card or serial console. (Using ssh and/or http) -Make automated install of system on new computers trivial. -Make FreeBSD a practical choice of OS for large cluster setups. * Deliverables: -Scripts to make it easy to setup a netboot server, running either on an existing FreeBSD machine, or a Freesbie LiveCD -rc scripts to launch BSD Installer onto machines which have just netbooted -daemon to tunnel BSD Installer frontend-backend communications over an ssh tunnel, allowing for control of multiple installs from a single machine. Depending on requirements the front end could be multiple curses in a "screen session", multiple CGI front ends in Firefox tabs or multiple QT windows on an X Windows system. (This could be particularly useful when installing in a school/college/office with many computers in different rooms, or when installing in a series of cluster nodes which lack both serial and local consoles, as well as CD & Floppy drives.) -Mechanism for local caching of packages to ensure effective use of Internet connection when installing packages. -The procedure will allow for fully manual and fully automated installs. (Using network loaded pfi.conf for BSD Installer) -I will ensure that netboot setup is backwards compatible with sysinstall for those who allready have extensive Install.cfg files or who don't feel comfortable using BSD Installer. -Supporting documentation for the handbook to describe how to carry out a network install. * Implementation Strategy: *So as to maximise the usefullness of my end project I will reuse existing software rather than writing new programs where possible. *Much of this project will involve writing "glue" in either lua or sh to present more options to the user within BSD Installer (eg. I will use BSD Installer; isc-dhcpd; FreeBSD's pxeboot program; Freesbie2 scripts and FreeBSD's tftpd) -Modify BSD Installer netboot setup proceedure to allow for use of existing DHCP server, add other improvements and options for netboot server setup. (BSD Installer requires that you use built-in DHCP server which makes it impossible to use in an environment with another DHCP server. I will solve this by providing the user with information to program into an existing server while also presenting options to launch a built-in server) -The BSD Installer Front Ends will need to be patched so as to properly support connecting to backends forwarded over ssh (eg. on ports other than 9999). -A series of shell scripts for creating tunnels and starting backends (which will log over NFS) on nodes, and starting Front Ends on server. -Scripts to setup some kind of proxy (probably Squid) to hold packages, clients will reqest all files from server, if the server is booted from CD ROM packages may need to be cached in RAM, otherwise they could go on HD. User will also need to choose nearest mirror site. mentor: simon? ------------------------------------- Kernel multipath routing support (SoC proposal from Mikhail Zolotaryov ) Improve route(4) to support multipath routes with (un)equal-cost load-balancing or/with fail-over, Improve route(8) to support multipath routes with (un)equal-cost load-balancing or/with fail-over. Improve netstat to show multipath routes. Make changes to man pages. mentor: andre? --------------------------------- bcm43xx driver (SoC proposal from Giuseppe Iannello ) Synopsis Kernel module for Broadcom wireless cards based on the bcm43xx chipset (i.e. Airport Extreme), using the specs from http://bcm-specs.sipsolutions.net/ Benefits to the Community This will let people use many wireless cards, as this chipset is used in a lot of pcmcia cards and bundled in many laptops. The module will support only STA mode, because specifications for AP mode aren't complete. Project Schedule Step 1 (until 25/06) Chipset initialization (a/b/g PHYs, various radio models) and periodic tasks. Interrupt management. Hooks to net80211. Basic packet RX (monitor mode). Step 2 (1 month) Packet TX/RX (PIO mode first, then DMA) Management functions (channel/rate/txpower) Authentication/association Step 3 (until 15/08) Hardware encryption. LED management. (If specs will be complete) Afterburner support (aka 125mbit mode) Testing, bugfix. mentor: sam? -------------------------- NMI Watchdog (SoC proposal from James Adams ) from proposal ideas list: 'Use the performance counters feature of i386/amd64 processors to periodically send an NMI to every processor, and make sure the kernel is still running correctly. Requires good knowledge of the i386 architecture and C.' This is not a perfectly straightforward task as it requires using the IO-APIC (there could be more than one) and/or the local APIC (one for each CPU). The basic idea is to send NMI (Non Maskable Interrupts) to each CPU at a regular interval to determine if a CPU has entered a locked up state and to bring it out of that state. I intend to end up with a feature similar to the one in the Linux kernel described here ( http://fxr.watson.org/fxr/source/Documentation/nmi_watchdog.txt?v=linux-2.4.22 ). A user will be able to setup a watchdog timer either via a compile time kernel directive or on boot via a FreeBSD sysctl. The feature will work on both uniprocessor and multiprocessor (or multi core) systems. Benefits to the FreeBSD Community: Having an NMI watchdog feature would be extremely useful for developers and users of FreeBSD to diagnose and solve frustrating hard lock up problems. As multiple processors and multiple cores on a single processor become increasingly more common this feature will be even more useful. Linux seems to have had this feature for some time and it seems silly for us not to support this, especially when the necessary hardware component is already there on our most common platform (*x86). mentor: ssouhlal? comment by jkoshy: PMCs are not architecturally defined in the x86 architecture and their programming interface can vary between CPU implementations. Much of the infrastructure to handle these differences is present today in hwpmc so I would suggest that this project extend hwpmc/libpmc rather than solve the interface issues from scratch. ----------------------------- Cheap Syscalls (SoC proposal from Spencer Whitman ) Benefits to the FreeBSD Community: Creating a global page shared by all processes will speed up several syscalls, as they won’t actually have to make syscalls, or can take better advantage of the hardware. Deliverables: 1. A page accessible by all processes to speed up selected syscalls. mentor: ssouhlal, scottl? research project! may not be committed, benchmarks needed --------------------------------------------------------------- Improve burncd(8) utility (SoC proposal from Stanislav Sedov ) The FreeBSD burncd (8) utility lacks support for many features (DAO/raw/packed writing modes, DVD+-R/RW support, can't provide information for media). I have added already initial DVD support code. Theare will be changes both in kernel and userland code. I think fixing burncd is very important, since freebsd currently completely lacks support for modern optical media. Also, there is idea to realize ISO9660/ufs image generator for burncd (probably add this feature to bsdtar). mentor: sos? comments by sos: I've been collecting a list of features etc for a rewrite of burncd. I firmly belive that burncd needs to be rewritten and not kludged up with new stuff. If this can be made to run in the right direction I'll take it under my wings and if not directly useable for replacing burncd it could make a start at it... ----------------------------------------------------- IPv6 feature parity (SoC proposal by Patrick Collison ) IPv6 deployment is gradually heating up, but most development attention still goes to IPv4. My proposed project is to verify that all recent additions to the TCP stack in FreeBSD (such as hostcache, Compressed TIME_WAIT2 State, TCP MD5 checksums, inflight bandwidth-delay limiter) work properly for IPv6, and implement them where they are unsupported, or fix where broken. mentor: gnn? Philip Paeps? does this clash with IPv6 SoC 2006 project? Comment from Chris DiBona (Google): Patrick is well regarded by Google. ----------------------------------------------- Intrusion Detection (SoC proposal from Keith Larimore ) Project Title: Intrusion Detection Possible Mentor: Robert Watson Benefits to the FreeBSD Community: Obvious benefits to system and network security. Deliverables: A new FreeBSD package along with documentation to detect the presence or activites of an unwanted guest. I picture a program similar to tripwire taylored to FreeBSD, with snort integration. I was hoping to get some more input from Robert Watson on the Audit projects, but he was in a hurry and only had time to write a brief email. Hopefully he can critique this. Without any objections I'd like to do this project in perl. Some basic features: *Monitor activity on security sensitive files *Determines the source and purpose of open files *Monitor log files *Checks binary integrity *Checks for known rootkits *The ability to monitor troublesome users more closely *The ability to "check in" with a Snort IDS on the network and determine whether attacks Snort picked up on are destined for the FreeBSD box, and if believed to be vulnerable it will send an alert. *Email, motd, sms alert capability -------------------------------------- Advanced Automatic Installer (SoC proposal from Andrew Turner ) Benefit: Make automated installations of FreeBSD more powerful than the current sysinstall Details: I will design and build an automatic installer based on the BSDInstaller It will use simple shell scripts to produce a configuration file. It will then use this configuration file to perform the installation process It will use much of the existing BSDInstaller modifications to the release Makefile to build as it is already a live CD and can easily be modified to produce a net-bootable system. The way this could work would be 1. Run the scripts in /usr/scripts/ and /usr/local/scripts/ in the order from rcorder(8). They will produce the file /tmp/install.conf with the configuration 2. Use this file to configure the installer to partition the system, select the dist's to install, install packages and configure the installed system The /tmp/installer.conf file will look like dists = { 'base', 'kernel/generic' } kernel = { 'generic' } rc_conf = { { 'ifconfig_rl0', 'DHCP' }, { 'hostname', 'foobar' } } This would be achived by a simple API by the following shell script #!/bin/sh add_dist base add_dist kernel/generic set_kernel generic add_rc_conf ifconfig_rl0 DHCP add_rc_conf hostname foobar The file systems will be configured by either a similar API or by using a pre-determined layout. For example: / 256M ad0s1 swap 1G ad0s1 /tmp 256M-512M ad0s1 /var 1G-2G ad0s1 /usr 10G- ad0s1 gmirror 120G ad1s1,ad2s1 label=foo /home 120G mirror/foo This will automatically generate the file system layout. The /tmp partition will be sized to be between 256 and 512 MB, the /var will also be automatically sized. All space left on ad0 will be used by the /usr after the other file systems have been adjusted to be the correct size. The /home file system is placed on a gmirror partition. It will automatically create the mirror and then build the file system. The src/release/bsdinstaller/bsdinstaller_shell.sh script will be modified to allow the selection of the backend depending on the environment. ----------------------------------------- brltty (SoC proposal from Levi Campbell ) Project Title: The brltty braille display on FreeBSD Benefits to the FreeBSD Community: There are several accessibility programs in the FreeBSD ports system, yet none of them provide acess to braille displays like the PAC Mate and Focus by Freedom Scientific, so by porting brltty, the FreeBSD project can fill in part of the gap in its accessability software. -------------------------------------------- Generic SampleRate link-adaptation module http://crewman.uta.edu/~spal/soc_app_sample.html mentor: sam? ------------------------------------------------ GEOM random access device class (gra) (SoC proposal by Ivan Voras ) Project title: -------------- FreeBSD GEOM random access device class (gra) Author: ------- Ivan Voras Mentor: -------- Poul-Henning Kamp? Synopsis: --------- A FreeBSD kernel GEOM class providing random access (at byte boundaries) of arbitrary GEOM providers to arbitrary GEOM consumers Project Description: -------------------- During its development, FreeBSD has discontinued support for "block devices" - i.e. system devices that provide user space applications with kernel buffered, byte-granular access to storage devices. Currently, storage devices are available to user space applications as character devices (for example /dev/ad0) which can only be accessed at hardware sector granularity (usually 512 bytes). Unfortunately, there are applications created on (and for) Linux and other operating system which rely on byte-granular access to storage devices, and which fail to work on FreeBSD. Due to flexibility of FreeBSD's GEOM layer, a GEOM class can be made which *simulates* byte-granular access on a sector- granular device. This project will create such a class, under the proposed name "GEOM random access" (gra). This work will be licensed under the BSD license. Technical Details: ------------------ The GEOM class will be implemented as a loadable kernel module, it will consume one arbitrary sector-granular device (including, of course, other GEOM providers such as RAID devices) and create one GEOM provider device with byte-granular access. To convert sector-granular access to byte-granular access it will maintain a small internal buffer pool. Issues of handling writes (i.e. how often to do physical device writes if an application writes a sector byte by byte) will be configurable at device creation time. More information on the GEOM framework can be found here: http://www.freebsd.org/cgi/man.cgi?query=geom&sektion=4 Benefits for FreeBSD: --------------------- Dealing only with raw storage devices has simplified FreeBSD's VM system, but introduced a compatibility problem with applications that rely on being able to perform byte-granular operations on devices. This project will allow some such applications to run on FreeBSD (notable exceptions are applications that don't use read() and write() calls, but something else, like mmap()). mentor: phk?, pjd? --------------------------------------