After a fair amount of clean-up, a lot of waiting for review, and some ruthless pruning, I and my colleagues at Solarflare finally got our net driver accepted for Linux 2.6.26. Meanwhile a larger version of the driver made it into Xen's Linux tree, along with dependent drivers to provide a secure fast path to the hardware from domU. Somewhere down the road we're going to have to resolve these two versions, but now I'm just pleased to have a working driver in-tree.
There are some other changes I've worked on over the past few months:
However, this is still only part of my work. My main task at the moment is to write more unit tests for our next NIC.
posted at: 16:15 | path: / | permanent link to this entry
I'm employed at Solarflare Communications in the test group, supporting the work of testers and developers by developing test frameworks. (We actually have very few pure testers and a whole lot of automation.). In a major break from my previous jobs, I've been working mostly in Python on applications for use in-house.
More recently I've become involved in maintenance of our network driver for Linux, starting with updating it to use current kernel coding conventions, and submitting for inclusion in the kernel. This has become a bit frustrating because while there are a lot of people prepared to run checkpatch and pick nits, there are not so many who will do a thorough review of a driver that's 20,000-odd lines long. And without someone doing that, it won't go in.
Meanwhile some of my colleagues have done some great work to accelerate Linux networking on Xen by having drivers in dom0 and domU cooperate to expose hardware resources directly to domU. Our hardware architecture supports many virtual NICs with their own packet queues and set of buffers, so this does not compromise the security of the physical machine and dom0. The results are very impressive.
The original motivation for the virtual NIC architecture was as a basis for a user-level networking stack, which can provide very low latency and reduced CPU usage. This software was originally proprietary but has now been released under GPLv2 as OpenOnload. Google invited two of my senior colleagues to talk about this - here's a video of their talk about user-level networking.
posted at: 00:24 | path: / | permanent link to this entry
posted at: 22:44 | path: / | permanent link to this entry
posted at: 03:43 | path: / | permanent link to this entry
As threatened promised, I have produced a renamed
version of Ion3 that should avoid upstream trademark claims and thus be
DFSG-compliant. Some translations are out-of-date, but I'll release a first
version now and try to get those updated later. The new name is ParticleMan.
When I put
the name to a vote some time back the winner was Iceparticle, but there's
already an icewm and I couldn't resist the
TMBG reference.
(Whoever suggested this name to me: I had already thought of it but forgot to
include it in the poll.)
The packages are in my repository for now.
posted at: 18:22 | path: / | permanent link to this entry
Since ries (ftp-master.debian.org) is still down, I've uploaded packages for the latest version of Ion3 to my own server. That's:
deb http://womble.decadent.org.uk/debian/ sid/ deb-src http://womble.decadent.org.uk/debian/ sid/
The repository is signed with my personal key.
posted at: 01:49 | path: / | permanent link to this entry
The DebConf 7 videos needed some post-processing, mostly to recover missing pieces from tape. I've done a large part of that, but it's not yet complete.
The video team to-do list has details of the recordings that still need work, and the sessions that we believe were not recorded. Please tell us if we did record some of these, and we will have another look through our tapes for them.
The conversion to "publication" formats (i.e. small enough to offer for download) was started at the conference and I have continued this at home over the past 2 weeks. Unfortunately this has been interrupted by some hardware failures. It looks like the CPUs in two of my PCs were running hot enough to be damaged (slowly) but not hot enough to trigger an alarm or automatic shutdown. The remaining conversions will be running mostly on my laptop, which is pretty fast and should be able to finish conversion of the recordings that are in a good state in about 2 days. However, some of the converted files may be broken and need some manual attention.
My upload bandwidth is only 448 kbit/s so the high-quality files will take about a week to upload.
As ever, the video files are being published on meetings-archive.debian.net.
posted at: 18:39 | path: / | permanent link to this entry
Not my title, but that of Peter Gutmann's presentation about PKI, specifically X.509 as used in SSL. It's informative, entertaining, and I suspect not as well known as it should be.
posted at: 23:43 | path: / | permanent link to this entry
Ion3 supports docked applications and is compatible with the docking protocols used by WindowMaker and KDE. Normally you would use:
dopath("mod_dock")
to load mod_dock, which provides a standard corner dock, toggled using MOD1+D.
However, recent versions also support docking applications in the status bar, in "system tray" style:
-- In cfg_ion.lua:
defwinprop {
class = "foo-window-class",
statusbar = "foo"
}
-- In cfg_statusbar.lua:
mod_statusbar.create {
...
template="... %systray_foo"
}
GNOME unfortunately uses a different dock protocol. However, the docker program can adapt from this to the WindowMaker protocol. So you can include a GNOME system tray in your status bar by including docker in your X session and this in your Ion3 configuration:
-- In cfg_ion.lua:
defwinprop {
class = "Docker",
statusbar = "dock"
}
-- In cfg_statusbar.lua:
mod_statusbar.create {
...
template="... %systray_dock"
}
posted at: 23:39 | path: / | permanent link to this entry
It's day 2 of DebConf and dvswitch is being used by many members of the video team. So I have a pretty good idea of what it does well and what I need to fix in it.
The most serious problem is that there's no way to start and stop recording from the GUI. That's actually controlled by starting and stopping the file sink, which runs on a remote machine. Here I have arranged to start it by running a command with ssh in the background, which is stopped by quitting dvswitch or with pkill! The result is that we can record a lot of junk between events, which has to be checked and then discarded, or alternately stop recording and risk missing the next event.
Also, we like to number our cameras: 1 for the speaker, 2 for the audience, 3 for slides. But dvswitch assigns numbers to sources in order of connection. I fudged around this by again using ssh to start the sources in the proper order after dvswitch.
Despite these and a number of other flaws, it seems that several people have been impressed by the ability to cover talks from multiple angles. I hope this will attract more people to contribute to dvswitch so that it can serve DebConf and other conferences better.
posted at: 02:09 | path: / | permanent link to this entry
The DebConf video team is using a large number of programs, some common and some of our own, spread across 20-30 computers. Some may be interested to know what this is.
Most of the custom software and configurations should be included in the debconf-video project on Alioth.
posted at: 02:07 | path: / | permanent link to this entry
Semi-annoying, semi-amusing:
I'm using Firefox Iceweasel 2.0.
posted at: 00:36 | path: / | permanent link to this entry
Continuing a trend of upstream control-freakery, the author of Ion has claimed Ion and Ion3 as trademarks and set out a trademark policy that will require Debian to rename it. I've created a poll for selecting a new name.
posted at: 13:55 | path: / | permanent link to this entry
I just released version 0.5.0 of dvswitch, the software DV mixer intended for use at DebConf 7. I believe I've met all of the video team's essential requirements and most of the desirables.
Unfortunately real video mixing seems to take a faster machine than I have at the moment and I very much doubt I'll have time to improve that much. Although I have implemented picture-in-picture mixing, it won't be usable and may result in frame dropping, so I've started a stable branch intended for DebConf 7 that doesn't include it. Version 0.5.0 is released from this branch and can be considered the first alpha test version. There's now a little over a month to test, fix bugs and make minor improvements on this branch.
posted at: 09:28 | path: / | permanent link to this entry
I've been meaning to attend the ACCU Conference for some years and finally decided to pay my own way for a couple of days this year. It was an opportunity to hear world experts on C++ and other programming topics and to a smaller extent to meet and socialise with other professional programmers.
I attended the following sessions:
This was a somewhat surprising choice of speaker and subject since I think most attendees work on proprietary software, but I think any sensible developer in the proprietary world will try to build on free libraries under non-copyleft licences, where appropriate. Mark talked about governance and leadership in "open source" projects (actually praising Debian for having a clear constitution) and about the need for good communication between projects, for example about release schedules. He seems to have accepted that Launchpad cannot be a single hub, and called for standard formats for, for example, exchanging information about related bugs between bug trackers. But it doesn't sound like he's ready to take the lead on that.
Andrei looked at the strengths and weaknesses of various error reporting mechanisms in C++ and introduced a technique for making error handling more flexible. Normally a function is designed either to indicate errors through its return value or to throw an exception on error. If a function returns an error indicator, it's easy for callers to ignore it. If it throws an exception on error, then a caller that provokes errors more often than the called function's author anticipated pays a high cost in processing time for those errors.
Andrei's solution involves a class template
Likely<typename T> whose instances hold either a
return value of type T or an exception. A function that
can fail has a specialisation of this template as its return type.
The caller can check for failure if it knows how to handle it, or it
can ignore it - in which case the conversion to T or the
destructor will throw the exception. This is clever but doesn't seem
to be entirely satisfactory. The destructor which throws does first
check that no exception is already being processed, avoiding collision
of the two exceptions and consequent abrupt termination of the
program, but this can result in errors being unexpectedly ignored.
A marathon 3-hour talk on designing and testing software, particularly C++ programs (the subject of his well-known book) as a set of well-defined components.
Lakos first defined these components as being "physical" i.e. sets of source files - normally a header file defining an interface, an implementation file, and a test driver file. They may also include metadata for the build system. He talked about the value of reusable components (as if this wasn't obvious!) and the risk of introducing circular dependencies - which essentially turn many components into one and reduce reusability - if we fail to keep track of dependencies. Software built out of components can be viewed as a hierarchy or stack defined by dependencies. In a large system, components with similar dependencies and dependents can be grouped together into packages or package groups to simplify a view of these dependencies.
He explained that the test driver's dependencies count just as much as the implementation's, because we cannot reasonably test a component until we have tested its dependencies. Test drivers should also be written to avoid depending on environmental settings and configuration, so far as possible.
Finally, and perhaps most importantly, he spent a long time talking about how to construct test cases and test data. I might try to summarise this in a later entry if anyone's interested.
Andrei began by complaining that OpenOffice Impress was even worse than PowerPoint, but being able to use Linux (specifically Ubuntu) more than made up for the pain.
He briefly presented four key ideas that he believes programmers should understand and be ready to make use of:
I think I've been convinced to write an article about standardisation of multithreading in C++.
Crowl gave an overview (similar to this) of the extensive work that's been done on standardisation of multithreading in the C++ language and library. This is one of the most important features in C++0x due to the increased parallelism mentioned above. The current semantics of multithreaded programs are not standardised, resulting in subtle but potentially serious differences between current C++ implementations that support multiple threads, and in the need for assembly-language code in programs that use lockless synchronisation. Much of this is also relevant to C and is being considered by the C standard committee.
Stroustrup recapped the 4 forms of syntax for initialising objects
in C++, some inherited from C and some necessarily invented for C++,
none of which are entirely generic. He noted the lack of a simple
syntax to initialise the elements of containers, which violates the
general principle that class types should have the same status as
built-in types in C++. He then introduced a new initialiser syntax
that he and others have defined for C++0x, which is a brace-enclosed
comma-separated list of values, similar to that used for arrays and
C-style structures (aggregates). Container types can define a
constructor with a parameter of type const
std::initializer_list<T> & and when constructed with
this new form of initialiser they will receive this wrapper for a
constant array of element values. For types that do not, the values
in the list are treated as arguments to some other constructor, if one
matches. Otherwise, for compatibility, this may be treated as
aggregate initialisation.
There was far too much information here for me to even begin to summarise. Suffice to say there are lots of good things coming bu the library committee will have its work cut out to get them all properly specified in time for the Committe Draft coming late this year.
I also met old friends and new, put faces to names from newsgroups and books, and got too little sleep.
posted at: 18:16 | path: / | permanent link to this entry
posted at: 15:19 | path: / | permanent link to this entry
Just as Gecko exposes a bug in the nv driver, it can also provoke poor performance in the ati driver. This turns out to be avoidable by configuring X to use the newer driver interface.
posted at: 01:11 | path: / | permanent link to this entry
For this year's DebConf, we (the video team) want to be able to use multiple cameras like at DebConf 5, where we had one for the projection screen and one for the presenter fed to an analogue mixer and a digitiser. At DC6 we had no mixer and no budget for one. Same at DC7 - unless we can do it with software. Toresbe had a go at writing one but didn't finish. I want to give it a go. So:
posted at: 01:18 | path: / | permanent link to this entry
This is my new blog for technical/geeky/Debian stuff. I'm keeping my LiveJournal for social and private matters and syndicating this one to Planet Debian.
I hope this separation will make me less afraid of boring LiveJournal readers with technical minutiae and Debian politics or boring Planet Debian readers with local social stuff, so I actually write more. Don't get too hopeful though.
posted at: 16:55 | path: / | permanent link to this entry