FreedomHEC trip report

  • Article

by admin on June 13, 2006 03:29pm

FreedomHEC trip report
On Friday the 26th of April I attended the FreedomHEC Un-Conference (Yeah I am late with posting it). This was a two day conference which was held on the 26th and 27th. I only attended the first day. The FreedomHEC Unconference was billed as:

The hardware unconference where you'll learn how easy it is to make your hardware compatible with free, open source operating systems such as Linux, and available to new markets such as servers, next-generation entertainment devices, and more.

Get answers on everything from kernel data structures to the fine points of licensing. Discover how participating in the Linux process is fast and simple, how the development process works, and where to get started.

It did not completely achieve this goal, but was very helpful to people who have never done device driver development for the Linux Kernel.

It was set up by Don Marti, and was attended by approximately 35 people of which 8 or so were current kernel maintainers. I think the enthusiasts outnumbered those people who would be writing company device drivers by 2 to 1.

The conference started with a suggestion session as to what people wanted to see so that a calendar could be created. As a result the first day calendar became this;

1.       SYSFS OVERVIEW

2.       LINUX SOCIAL ENGINEERING

3.       SCSI Q AND A

4.       ROCKETS

5.       GETTING DRIVERS INTO THE KERNEL Q&A

Below are more details on the conference. My apologies if this at times is confusing, but I am working off my notes here...

1.     SYSFS OVERVIEW

This was an overview given by Greg Kroah-Hartman, who is the current Linux PCI tree maintainer (Among others he also does sysfs, kobject, debugfs and kref code). He works for SuSE Labs at Novell.

He presented a high level walkthrough of the sysfs subsystem (the /sys area) This is only available in the 2.6 kernels and is still evolving.

Sysfs (/sys) is a RAM file system, so anything created in there by humans after boot will be lost after any subsequent boots.

-sysfs shows all of the devices (virtual and real) and their inter-connectedness

In the past /proc has been used but /proc should be used for processes and not device drivers.  /proc is the older method of creating device driver configuration files.

One of the reasons that /sys exists is to standardize configurations of various device drivers. /proc has been used/misused in the past for configuration representations/files/atributes, the data under this file system are different from programmer to programmer and device to device and are very hard to interpret unless you know the format.

/sys changes all that.  It provides a standard method of defining and using device driver attributes. It is based off the principle of one value per file. And this value can only be a simple value, no histograms or large binary configurations (debugfs is specifically for this purpose!). Still people seem to break these rules at times.

Do a tree under /sys to see what the structure is, and cat the files for the values.

Power management used to turn things on or off, is not fully working yet. USB is getting there for power management; the rest, not yet.  Put in a USB Pen drive for example and see /sys/block change real time (/sys/block/sda). If you unplug a device, udev will take care of cleaning up. You do not have to un-mount or do anything else. (If you do that to a drive you are writing to, of course you are on your own) You can also mount things by label easily.

If a change is made to a device attribute in /sys, an event is triggered that programs like hal can get real time. General guideline, if you write a user space program/driver, tie it into hal.

Also, /dev is now a RAM file system in 2.6 (Some distro’s might not have implemented this)

If you want to add proprietary drivers, they will live in /lib/usdev/devices, this is when they are not sysfs aware. This location is persistent.

2. LINUX SOCIAL ENGINEERING

This presentation was given by Randy Dunlop, A past USB and Kernel Janitor and maintainer.

The presentation was given to give people an overview of do’s and don’ts when they start submitting code to the kernel. A lot of the information given was common sense but a lot of people do not follow the rules.  (e.g  Rules so Obvious that they are not followed)

The presentation was very much in Bullet form and so are my notes on this, so they might not flow as well as they could.

SOCIAL ENGINEERING

(Meritocracy) Development.

Massive amounts of open communication via email etc.

LINUX CULTURE

    • Community alliance is high
    • do what is right for Linux
    • Meritocracy - style, values and culture
    • Ideas are good, but back it up with code.
    • Driven by ideals and pragmatism, bottom up dev
    • Not driven by marketing req.
    • Don't just take, give back to.
    • Following standards
    • Compatibility with other systems.
    • RERO release early release often. Get feedback.  Bad side is flames, embarrassment.
    • Treat people with respect.
    • Continues code review and improvements.
    • Follow the culture
    • Code speaks louder than words

LINUX DEVELOPMENT VALUES

    • Pragmatism, not theory
    • Code not talk
    • Performance
    • Technical merit, not politics/who/or money

THINGS TO AVOID

    • Patents, binary modules
    • NDA
    • Proprietary benchmarks
    • Making demands instead of requests
    • Adding more IOCTL :-)
    • Marketing
    • Design documents

WHEN NEW INFRASTRUCUTRE IS NEEDED

DRIVERS FOR NEW HARDWARE

    • Need GPL license to add to the kernel. Or HW, with specs and approval to make resulting code GPL.

NEW DRIVER DEV

    • Requires >1 dedicated full time sw eng to keep up with mailing lists.
    • Continuous commitment
    • Stable Kernels are 2.even.  dev cycle Kernels are 2.odd trees

COMMUNICATIONS

    • Best way to communicate, keep it short and constructive and use mailing lists, no need to meet.
    • Dev conferences.

MAILING LIST etiquette

GENERAL

    • Check out OSDL
    • User API is very stable and will remain so.
    • Kernel API is not stable. A static API limits innovation and adds "cruft"

In all the presentation was a crash course for people who have never done collaborative development, and tried to prepare people what is ahead and what kind of commitment will be needed to be part of the Linux kernel development.

3. SCSI Q AND A

Led by James Bottomley SCSI Subsystem maintainer.

I do not have many notes on this part because not much was said to keep notes on, a few things that I did write are as follows (Second item is of great  interest)

If you want to get an idea of how SCSI drivers work, check out the 53c700 which is an excellent driver to learn from. It is older but continuously maintained.

There is kind of a new concept called a Target driver. Target drivers make it appear to the outside world as if it is a driver (A virtual driver more or less), but instead connects to the actual physical device drivers. Allowing, for example, to turn a Linux box into a RAID device. Then you can talk to the target driver as if it is one device. Not many of them out there yet, but there is one from IBM which James did not think was a very good. And there are a few on the way.  There are two people (names escape me currently) that are actively developing them. In my opinion this is a pretty interesting concept that allows you to do a whole bunch of cool things. (e.g Network routers, Cheap raid devices etc)

You can (should?) write SCSI drivers in user space.

4. ROCKETS

A lighter presentation was given by two students from Portland state. They are using Open source hardware and software to build rockets. Some interesting reads can be found on that project here:

https://psas.pdx.edu

5. GETTING DRIVERS INTO THE KERNEL Q&A

This was pretty much done by Greg.

Some source code control software of choice of the Kernel Maintainers

    • Quilt source code for patches.
    • Git for main tree.
    • Hg

Testing Kernel code is hard, but crashme is used by the maintainers be used for (stress) testing kernel stuff.

Greg was very adamant that they take any device driver. No matter what HW it uses, as long as you or somebody else is willing to maintain it they will take it.  Old/New it does not matter. Even if there is only one user for it they will take it.

That’s all folks.