Minnowboard:GSoC2015

--== Google Summer of Code 2015 - Ideas Page ==--

= About: =

The MinnowBoard project is an open hardware platform that uses Intel Architecture. While the project, overall, is focused on hardware there are a lot of things surrounding this effort that can, and are, useful both to the project and to the greater open source community. As such the MinnowBoard project (from a GSoC perspective) is more of an umbrella giving a home to a number of other projects to collectively work on and around the enablement of the MinnowBoard.

= Why is this important? =

These projects not only help the MinnowBoard project, but also enable other open source projects and software. These tend to be smaller projects or projects that are more tightly focused and would not otherwise be apart of GSoC, but that could benefit from additional contributors.

= What we are looking forward to in GSoC 2015 =

There are a number of projects that are being looked at, they are grouped by their overall focus. Areas of expertise are wide ranging from proficiency in perl and file synchronization, network booting (with specific emphasis on booting over the internet), uefi firmware programming,

For development purposes a MinnowBoard MAX, a serial cable, and power adapter, will be shipped to accepted students.

How to find us
The best way to find us is on IRC (Internet Relay Chat), and start with #minnowboard@irc.freenode.net

A web based IRC client can be found at http://webchat.freenode.net/?nick=MinnowBoardGSoC.&channels=minnowboard&uio=d4

We've also got a mailing list at http://lists.elinux.org/mailman/listinfo/elinux-minnowboard

= Ideas =

About:
SyncDiff(erent) is a state-full file synchronizer, with ideas shamelessly stolen from rsync, git, csync2, unison and probably a variety of other places. Two of the major design goals were to lower the time it takes to determine what has changed on disk (particularly in comparison to rsync), and to allow allow for multi-way synchronization using a star topology, and accepting eventual consistency. This is interesting to the MinnowBoard project as it's used, in minor ways, around our own infrastructure and we want to increase it's usability and approach-ability.

HTTP Accessor
Mentors: John 'Warthog9' Hawley, Greg Lund-Chaix

Difficulty: Medium

Right now SyncDiff(erent) currently transfers files using a slightly custom protocol over TCP. This project would add an intermediate CGI that would allow a client to communicate with the server running via a web server. The communication protocol involves JSON.

Requirements:
 * Perl
 * Understanding of IPCs and Multi-processed programs
 * Basic understanding of TCP/IP
 * Knowledge of Wireshark, and ability to run it
 * Good understanding of CGI interfaces
 * Understanding of Apache and Nginx (targeted web servers, knowledge of others beneficial)

This may require extension or modification to the current protocol, and students should be willing to make suggestions and recommendations, if that is required to meet the end goal.

SSH Transport
Mentors: John 'Warthog9' Hawley, Greg Lund-Chaix

Difficulty: Medium

Right now SyncDiff(erent) currently transfers files using a slightly custom protocol over TCP. This project would allow for that stream to happen over an authenticated SSH connection, as opposed to the straight TCP connection, similar to scp, sftp, rsync, etc. The communication protocol involves JSON.

Requirements:
 * Perl
 * Understanding of IPCs and Multi-processed programs
 * Basic understanding of TCP/IP
 * Knowledge of Wireshark, and ability to run it
 * Good understanding of ssh

This may require extension or modification to the current protocol, and students should be willing to make suggestions and recommendations, if that is required to meet the end goal.

TLS implementation
Mentors: John 'Warthog9' Hawley, TBD

Difficulty: Hard

Right now SyncDiff(erent) currently transfers files using a slightly custom protocol over TCP. This project would add TLS to the communications channel to encrypt all traffic being transferred. The communication protocol involves JSON.

Requirements:
 * Perl
 * Understanding of IPCs and Multi-processed programs
 * Basic understanding of TCP/IP
 * Knowledge of Wireshark, and ability to run it
 * Understanding of TLS communications, including how revocation certificates work

This may require extension or modification to the current protocol, and students should be willing to make suggestions and recommendations, if that is required to meet the end goal.

About:
SMBus is an extension of I2C used for system management. PMBus is an extension of SMBus used to manage power systems. SMBus is used for battery management and other system functions, and PMBus is used to manage power in equipment used in data centers, such as servers and routers. It is common for a system to have a Board Management Controller (BMC) based on an application processor running Linux. The Intel Atom is an ideal platform for BMCs because of broad support for compiler technology targeted at I32/I64 instruction set. For example, Haskell, a functional language, compiles and performs well on a MinnowBoardMax running Ubuntu 14 TLS.

SMBus Kernel Support
Mentors: Michael Jones, John 'Warthog9' Hawley

Difficulty: Medium

The SMBus 3.0 specification was recently released, and Linux does not fully support the changes to the specification, and the MinnoeBoardMax drivers do not fully support the specification. The SMBus driver architecture and API needs to be updated as well as adding full support for MinnowBoardMax including:

Goals:
 * Fully support PMBus Protocols (Can implement them using /dev/i2c* ioctl and Linux smbus API)
 * Support 256 byte block commands
 * Support on the fly clock rate changes via /dev/i2c* (ioctl and Linux smbus API)
 * Support asynchronous callbacks to a user space application for SMBALERTB using MinnowBoardMAX GPIO
 * Support configuration and choice of GPIOs for SMBALERT from /dev/i2c (ioctl)
 * Other SMBus functions as discovered to be missing all available to user space applications
 * Code accepted into the mainline kernel git server

Requirements:
 * C
 * Understanding of Linux driver architecture and compiling and debugging the Linux kernel
 * Knowledge of /dev and ioctl based user applications
 * Basic understanding of Ubuntu, gcc, apt-get, and standard development tools

This may require extension or modification to the current Linux smbus API, and students should be willing to make suggestions and recommendations and lobby the community, if that is required to meet the end goal.

Haskell SMBus/PMBus Module
Mentors: Michael Jones, John 'Warthog9' Hawley

Difficulty: Hard

There are Haskell modules available for USB and UART, but not for I2C/SMBus/PMBus. Tool builders and robotics enthusiasts in the functional programming community could use supporting modules.

Goals:
 * I2C/SMBus/PMBus modules with reusable abstractions
 * Support multiple implementations of a single abstraction (classes) with a late binding (building blocks connected at runtime)
 * An implementation for MinnowBoardMax running on Ubuntu with the latest Kernel including SMBALERT and ARA
 * Use new features from the SMBus Kernel Support as available
 * Publish on GitHub and Hackage

Requirements:
 * Basic C skills
 * Haskell (way more than hello world)
 * Haskell Foreign Function Interface (FFI) and H2C experience
 * Basic knowledge of /dev, ioctl, signals, on Linux
 * Basic understanding of Ubuntu, gcc, apt-get, and standard development tools

This project requires pre-existing Haskell skills. It is best if the student has familiar with Lamba Calculus and Category Theory, but more important is practical applied skills writing real code.

= How things work / What do I do now / How do I proceed: =

So a lot of students this may be their first year participating, or you may never have worked with us, so lets break this down:

February 20th - March 16th: Students are encouraged to start looking at the project, join the IRC channel, talk on the mailing list and generally interact with us. This will help you get a feel for who we are, and if you want to work with us. This is a great time to ask about the ideas we have up too, and to start thinking about what you might want to work on.

March 16th - March 27st: Students should be working on their applications. This is a collaborative process, we want you to ask questions, get feedback, make revisions and make as good a proposal as possible. Holing up and not talking to us will make your proposal suffer.

March 27th - April 27th: This is where our organization is going to differ from some others. Students will be asked to sit down with us for a 1hour long IRC based interview during this time. We will discuss your proposal, ask you questions and there will be a coding exercise or two. Students shouldn't feel the need to cram, or worry much about this, this is mostly a time to chat with the student and for questions to be traded. This interview is, however, required by our organization.

March 27st - April 27th: This time period in general is for more discussion to be happening with the students and organization. Submit bugs and patches, talk with the mentors. A general hint, lobbing the application at us and disappearing will generally count against you. Stick around, and keep the conversation going that you've already started.

April 27st: Notifications go out to students about acceptance. At which point the summer really starts!