LJ: What decisions were made at the summit that you didn't expect or that the kernel developers might not have made over e-mail?

Ted: There weren't really any decisions made at the summit because that wasn't really its purpose. The main thing I wanted was to give people a chance to have some high-bandwidth, low-latency conversations, the sort of thing which is done much better in person. It was also helpful in that it's harder to flame someone and easier to have a civilized discussion in e-mail if you've already met someone in person. It helps to calibrate the other person's cyber- and real-life personality.

For example, my hope is that the acrimony between Donald Becker and Jeff Garzik will be a thing of the past now that they've had a chance to meet each other.

As always, the decisions will be made using the all-important criteria, "show me the code". But given how much more complicated the kernel is, it's useful to have some design discussions before actually sitting down and coding stuff up, so that people know about potential objections and/or pitfalls ahead of time.

LJ: What's on your personal to-do list from the summit?

Ted: Well, the things on my to-do list haven't really changed. I'm planning on doing a revamp of the tty layer, and I have some ongoing ext2/ext3 work that I'd like to do. These aren't really things brought up at the workshop, though.

I will say there are a lot of things folks are planning on working on in 2.5 that I'm really looking forward to, though.

LJ: OK, you made me ask...what's going to be really cool in 2.5, and what's going to be really hard in 2.5?

Ted: Zero-copy in the networking and block device layers. Better scalability in the block device layer in general. No more two terabyte limitations, which is a good thing given that it might not be long before it becomes a real, fundamental limitation, even for "normal" systems.

Kernel support for Async I/O is also going to be very important.

As for what's going to be really hard, none of it. It's all a Small Matter of Programming.