Linux Kernel 2.6.31 Released

diegocgteleline.es writes "The Linux kernel v2.6.31 has been released. Besides the desktop improvements and USB 3.0 support mentioned some days ago, there is an equivalent of FUSE for character devices that can be used for proxying OSS sound through ALSA, new tools for using hardware performance counters, readahead improvements, ATI Radeon KMS, Intel's Wireless Multicomm 3200 support, gcov support, a memory checker and a memory leak detector, a reimplementation of inotify and dnotify on top of a new filesystem notification infrastructure, btrfs improvements, support for IEEE 802.15.4, IPv4 over Firewire, new drivers and small improvements. The full list of changes can be found here."

Comments

IPv4 over Firewire?

[0100010001010011]

I guess I really wasn't into linux until the last 3-4 years, but hasn't OS X done this since the start? And I think my XP machine at work tries to use Firewire as a network adapter.

What took so long, honest question.

Re:IPv4 over Firewire?

[muckracer]

Networking over USB would be awesome. Link 2 PC's with USB cable and voila! Hell, even being able to mount an internal drive that way on the other machine would be cool. Anything like that in the works (haven't checked)?

Re:IPv4 over Firewire?

[Lemming Mark]

How was the parent modded troll, it's completely valid!

It's a good idea. There have been networking over USB devices (by which I mean plugging both machines USB ports into the device, not "merely" a USB ethernet adaptor). The problem with doing this with USB, rather than Firewire is that USB has a really strong concept of "host" and "device". The cables are made to only plug into certain combinations of endpoints because, sadly, only certain combinations of endpoints can possibly work. You can't plug the host controller of one PC into another, since they're only expecting to talk to devices, not another controller. This is in contrast to Firewire, which is peer-to-peer and (in principle) anything could talk to anything over it.

The unfortunate consequence is that you don't just get to do networking over a nice, cheap cable as you do with Firewire. You actually need a little device box in between so that both hosts can believe they're talking to a peripheral, not another host. This approach, on its own, wouldn't let you plug in "remote" devices either so you'd have to set some other protocol up (plenty of existing options here) to talk to devices at the other end. You have to be a bit careful because most devices would barf horribly if there are multiple users - uncontrolled shared access to a disk device is a good way to lose all your data, for instance.

Although it's fun to do IP over Firewire, I'm not familiar with exactly how it's implemented. What intrigues me is the prospect of running increasingly sophisticated high-performance protocols over Firewire. As I understand it you can basically get remote DMA access to the "other end's" memory. This obviously has severe security implications but it could be quite nice in a mutually-trusting cluster. There are various protocols (e.g. used by Infiniband) for having communications over remote DMA. I wonder if anyone could put together an "infiniband lite" that just ran over Firewire. It'd be cool, though I don't know if it would be particularly useful ;-) (plus it would lack the user accessible networking Infiniband has)

Re:IPv4 over Firewire?

[fuzzyfuzzyfungus]

For tape-based systems, or for situations where a chain of components are expecting a DV stream to be arriving on schedule, you really can't beat firewire. And, for that reason, nearly any PC being used for DV editing will have firewire onboard. Nicer motherboards have it standard, PCI/PCIe expansion cards are cheap if yours doesn't.

However, the trend in camera tech, at least at the consumer level, is making that increasingly irrelevant. Flash and HDD based camcorders are gradually devouring DV camcorders in the lower end market. Pretty much all the HDD or flash based cameras(at least the ones that cost less than the computer they are connected to) just show up as USB mass storage devices, with one or more video files on them. Drag and drop and go. Unlike DV, where the transfer requires that X megabits per second make it from point a to point b, on time, or you'll get glitches, mass storage just requires that all the bits get from point a to point b before the user gets bored. USB still isn't quite as good as firewire at doing that; but the difference in performance is small, and the difference in price/convenience is large.

Once you get away from the real time streaming requirements of DV, to which firewire is well suited, transferring video is just a special case of connecting an external hard drive. Firewire is better there; but only modestly, which isn't really good enough to survive on the price sensitive end of things.

70% drivers!

[millwall]

Lots and lots of driver work. Over 70% of all of the 2.6.30 to 2.6.31 patch is under drivers/, and there's another 6%+ in firmware/ and sound/. That's not entirely unusual, but it does seem to be growing. My rough rule of thumb used to be "50% drivers, 50% everything else", but that's clearly not true any more (and hasn't been for a while - we've been 60%+ since after 2.6.27

I personally think this is a real pity. So much time is being spent on getting drivers implemented that new features and other kinds enhancements are being pushed back.

Support for what?

[saleenS281]

Support for what? A quick search of newegg tells me I can't buy a motherboard, add-on card, or peripheral that supports USB 3.0 today. What exactly was windows 7 going to support? An unreleased chipset?

From your own article:
Jeff Ravencraft of Intel said that he expects the final specification to be announced in San Jose, Calif., on November 17.

Wait, so I'm supposed to be upset that Microsoft didn't ship experimental drivers for an unratified standard in their new OS?

Re:Support for what?

[jbeaupre]

Don't be upset with MS, be happy for Linux. In fact, with support built in, Linux will frequently be used to develop and test the hardware. So some of the early USB 3 products will be de facto optimized to run with Linux.

Re:Linux audio

[walshy007]

OSS made it impossible to play more than one stream at once on a lot of hardware.

With a standard configuration, alsa does also, you have to load the dmix module in your config to act as a software mixer on cards that don't do hardware mixing (most on board bits).

This is where the userspace demons enter it all, most of them just started out as another layer that does software mixing, but every man and his dog came up with his own invention.

As for just using alsa, that's great if you don't mind not having certain functionality, some of the sound demons do add some nice features (jack is the only one I've found worth using though). It could be argued the driver layer shouldn't have to deal with some of that advanced functionality though, another reason why these demons were made.

Re:Linux audio

[bluefoxlucid]

What IS the PA latency, and the Jack latency? Jack seems idiotic; just use the sound card directly. Seriously, consider this: JACK -> ALSA, you can go directly to ALSA anyway (I haven't had a sound server for years). Do the mixing in your application and output it to ALSA. If real-time performance is an issue, don't run multiple apps at once. Record separate tracks versus a (monitored) metronome(!) when doing music, and then merge them with Audacity or GLAME.

"Professional" audio amateurs seem to all be n00bs, using their recording device (computer) for playback whereas real "professionals" use monitors, metronomes, visual cues, and master tracks. You monitor your metronome, monitor yourself, monitor the playback track, whatever; and record a separate track. Then later you digitally merge those together. QED. Whatever stupidity relies entirely on your computer being able to low-latency its way out of a paper bag for you to get any work done is a huge engineering error.