Version numbers do mean nothing, we have always said that as kernel developers.
We don't break external APIs that people use, we break internal ones all the time, for good reasons. Read stable_api_nonsense.txt in the Linux kernel source tree for why we do this.
And I will take _any_ kernel driver into the tree, just send it to me, we don't reject anything, much to many people annoyance...
greg k-h
Re:sadly, your numbers are bogus
on
Bitkeeper News Redux
·
· Score: 3, Informative
Not true, a number of the main kernel developers use bitkeeper to show who the original developer of the patch was. I know I do, as does Dave, Jeff, and a few others.
Some notible exceptions are Andrew Morton and Rusty's kernel patch monkey. So for people who sent in patches through them, yes you are correct. But the original patch author can easily be determined by looking at the changelogs for those submitted patches. It also would not be that hard for someone to go through and properly fish out the "real" numbers if they so wanted.
But the rate of change is the same, either way.
Here's the rate of change for 2.6
on
Bitkeeper News Redux
·
· Score: 5, Informative
Larry referenced some stuff I wrote for Open Source magazine recently. Here's the basic information if anyone wants to know what the real rate of change was for the 2.6 kernel development cycle. As for if it is faster than 2.4 we don't have real numbers (bk wasn't being used) but you can take the diffs and compare them for yourselves...
The Linux 2.6.0 kernel was released after 680 days of development. Here are some statistics about the development cycle during that time period:
- 27149 different changes were accepted into the kernel source tree. That averages out to about 1.66 changes per hour over the entire 680 days.
- 916 different developers contributed at least one kernel patch.
- 413 different developers contributed one kernel change.
- 117 different developers contributed two kernel changes.
- 57 different developers contributed three kernel changes.
- 38 different developers contributed four kernel changes.
- 20 different developers contributed five kernel changes.
- The top 10 developers contributed 10933 kernel changes.
- The top 5 developers contributed 6956 kernel changes, averaging out to about 10 kernel changes a day.
- There were 6175 merges in the kernel source tree, averaging out to about 9 merges a day.
- Including merges and code changes, there were just over 2 modifications per hour over the entire 680 days of development.
Whoa, it is definetly not their problem that linux USB support is not up to par???
The main problem why Linux does not have support for as many different USB devices as Win98/2000 do, is because of companies not releasing their specs to their vendor specific devices for anyone to write Linux drivers.
That is it, plain and simple. If a device meets a USB device spec, then odds are Linux supports it. If not, and the device uses a ventor specific protocol, then odds are Linux doesn't, and will not, unless someone reverse engineers the protocol, or the vendor releases the specs.
And reverse engineering the protocol isn't really worth it anymore, most of us Linux USB developers would rather work with the companies that do release their specs.
So yes, it is the vendor's fault that the Linux USB support isn't "up to par" with Windows.
Odd, but I include a patch for 2.4.0-test8 on the Immunix CD, and on our web site right here. It applies with some fuzz on 2.4.0-test12, and I'll update again on Tues for this release.
I've also been releasing this patch on the linux-kernel mailing list, as well as the stackguard mailing list for the past couple of months.
And if you have any problems with this distro, the developers are all on the stackguard mailing list, and very responsive.
As for it not being a kernel hackers special I would dispute that, as I do all of my kernel work on this os:)
Im excited about the USB interface...on Linux... Take a look at the latest kernel, LOTS of USB devices are supported.
Will people STOP saying Linux does not have USB support! For the number of times I keep hearing it, I almost would start believing it, if I wasn't currently typing with my USB keyboard and using my USB HandSpring Visor docking station all the time...
On a related note, some people just got the RIO MP3 player working with the Linux USB stack, take a look at http://rio500.sourceforge.net for more information on it.
Sorry to say, but the Symantic jobs in Eugene is for tech support only. Not really high tech. There are a few places in town, PSC Inc and there was Percon. They are both high tech embedded systems and application programming jobs with stable companies (PSC just bought Percon though).
The Hundai plant is manufacturing only, as is the HMT and Sony factories.
But don't get me wrong, it's a great town, and I'm glad I live here. Moved here from Pittsburgh too (keeping on topic) and glad I did.
USB is up and running just fine in the 2.3.x series of kernels. There is even a backport of the USB stack into 2.2.12 right here Also check out the USB HowTO for getting started.
Thank you for identifying your vested interest. That's all too rare around here. No problem.
In other words: yes, Firewire will over the long term retain a significant raw-bandwidth advantage despite very short-term leapfrogging. Correct. Firewire will probably always be faster. And it deserves to be that way. The USB group is only starting to work on the issues of higher speeds that Firewire solved a long time ago.
My question is: what speed issues did people have that would not have been adequately addressed by implementing both USB and Firewire? As many people including yourself have pointed out, there are still and will always be important differences between the two, and "one size fits all" is more often than not a lousy philosophy in computing. I don't know. I think that this is more a political issue rather than a technical one.
I have nothing against USB in and of itself. My concern is that Firewire already exists and as near as I can tell already addresses the issues which USB2 seems to be trying to address (as compared to USB1). I happen to dislike reinvented wheels; I would have been much happier if the USB folks had let USB do what USB does best, and let Firewire do what Firewire does best, and go off to do other more useful things with their time. Competition is great, but there's plenty in both technical areas already. Pushing USB into the Firewire "problem space" is just an attempt by Intel to squash competition in the high-speed interconnect market by leveraging their position as the largest PC chipset manufacturer. I agree.
It seems that Intel and other manufacturers are a little pissed about the licensing fees that go along with Firewire. So they bumped USB up to take care of the speed issues that were remaining with some devices (audio, mass storage, video). Now Intel can just implemement one chip on it's motherboards, and not have to worry about having to licensing money to anyone else.
I am remaining real sceptable. The rollout plan for operating system support, and silicon support is VERY aggressive. The hub model is VERY complex. True USB 2.0 support in both devices and hosts will be a number of years in the future.
Now does anyone have any ideas of what just happened to Device Bay (USB & Firewire working together)???
OK, I'm actually at the USB 2.0 Devcon right now, and have read the 2.0 proposed spec, so I'll take a stab at refuting these comments:
1.The usb.org article only claims "120-240Mbps". It's not clear where the ign.com article came up with 480Mbps. The speed is 480Mbs. That is what the spec says.
2.Even if USB2 runs at 480Mbps, the Firewire folks aren't exactly standing still. Any raw bandwidth advantage of USB2 is sure to be short-lived at best. Firewire and USB have too many things that are not in common, they really are not competitors. USB is aimed to be a PC centric bus. There has to be only one host, and a whole lot of clients. Firewire can be host to host. Firewire is more intrenched in the consumer electronic market, while USB is sticking to the PC (for now).
3.There's lots of blather in the USB2 announcement about supporting video cameras etc. but IIRC USB doesn't support the isochronous transfers which are usually considered necessary to serve those markets. Did I miss something? You missed something. USB has always supported isochronous transfers. Look at the USB speakers from Philips for an example of a shipping product that uses this. Isochronous is still there for 2.0.
4.Another useful Firewire feature that USB doesn't seem to have is providing power through the same connector used for communications. Again, I may have missed it. USB has ALWAYS supported power on the connector. How else does some of the devices work? 2.0 does not change this. It's still 5V at 100mA-500mA depending on what you need and ask for. If you need more power, take a look at the Plus Power Connector that IBM supports for USB. It can provide 12V or 24V at 3A. That's about all the current that anyone needs.
5.I don't remember how many devices USB supports, but I suspect it's less than Firewire. USB supports 127 devices per host controller. You can plug in more than one host controller in your PC at a time. The record (I think) for most devices plugged in and working at once is around 144.
6.I know that USB-based host-to-host networking exists, but it's not clear to me whether it's really as well suited to that task as Firewire. In particular, I wonder how much asymmetry between hosts and devices (a la initiators and targets in SCSI) is built into the protocol, and how round-trip latency compares to other technologies. As I said above, USB is a host-client bus. You can make (and buy) a device that does networking over USB from one computer to another, but this is just two client devices talking together in a box. Firewire can do true host to host on the bus itself. The USB protocol is a star topology with the PC host controller at the top. I can look up the round trip latency stuff somewhere, but it is built into the protocol, and the host and hub controllers seem to handle it well.
7.Similarly, I'd like seeing a comparison of how automagically reconfiguration happens when devices are added or removed using each technology. I don't really know how Firewire does this at all, but USB handles this wonderfully. There is a description of how the protocol handles all of this in the spec (at www.usb.org). In summary, USB 2.0 looks like it handles a lot of the speed issues that some people had with 1.1. It provides backward compatibility with all 1.1 and 1.0 devices and enables things like speakers and video cameras to run better. Like it or not, USB looks to be here for a while. A lot of computers are coming out without a lot of different connectors, and USB is replacing them.
Ob Linux: USB is working on Linux in the 2.3.x series of kernels (it's also supported a little in the 2.2.x series, but not for many devices.) More information is at www.linux-usb.org
Slashdot Mirror
Version numbers do mean nothing, we have always said that as kernel developers.
We don't break external APIs that people use, we break internal ones all the time, for good reasons. Read stable_api_nonsense.txt in the Linux kernel source tree for why we do this.
And I will take _any_ kernel driver into the tree, just send it to me, we don't reject anything, much to many people annoyance...
greg k-h
Not true, a number of the main kernel developers use bitkeeper to show who the original developer of the patch was. I know I do, as does Dave, Jeff, and a few others.
Some notible exceptions are Andrew Morton and Rusty's kernel patch monkey. So for people who sent in patches through them, yes you are correct. But the original patch author can easily be determined by looking at the changelogs for those submitted patches. It also would not be that hard for someone to go through and properly fish out the "real" numbers if they so wanted.
But the rate of change is the same, either way.
Larry referenced some stuff I wrote for Open Source magazine recently. Here's the basic information if anyone wants to know what the real rate of change was for the 2.6 kernel development cycle. As for if it is faster than 2.4 we don't have real numbers (bk wasn't being used) but you can take the diffs and compare them for yourselves...
The Linux 2.6.0 kernel was released after 680 days of development. Here are some statistics about the development cycle during that time period:
- 27149 different changes were accepted into the kernel source tree. That averages out to about 1.66 changes per hour over the entire 680 days.
- 916 different developers contributed at least one kernel patch.
- 413 different developers contributed one kernel change.
- 117 different developers contributed two kernel changes.
- 57 different developers contributed three kernel changes.
- 38 different developers contributed four kernel changes.
- 20 different developers contributed five kernel changes.
- The top 10 developers contributed 10933 kernel changes.
- The top 5 developers contributed 6956 kernel changes, averaging out to about 10 kernel changes a day.
- There were 6175 merges in the kernel source tree, averaging out to about 9 merges a day.
- Including merges and code changes, there were just over 2 modifications per hour over the entire 680 days of development.
Whoa, it is definetly not their problem that linux USB support is not up to par???
The main problem why Linux does not have support for as many different USB devices as Win98/2000 do, is because of companies not releasing their specs to their vendor specific devices for anyone to write Linux drivers.
That is it, plain and simple. If a device meets a USB device spec, then odds are Linux supports it. If not, and the device uses a ventor specific protocol, then odds are Linux doesn't, and will not, unless someone reverse engineers the protocol, or the vendor releases the specs.
And reverse engineering the protocol isn't really worth it anymore, most of us Linux USB developers would rather work with the companies that do release their specs.
So yes, it is the vendor's fault that the Linux USB support isn't "up to par" with Windows.
greg k-h
Linux USB developer
Kernel compiling a bitch with Immunix OS?
:)
Odd, but I include a patch for 2.4.0-test8 on the Immunix CD, and on our web site right here. It applies with some fuzz on 2.4.0-test12, and I'll update again on Tues for this release.
I've also been releasing this patch on the linux-kernel mailing list, as well as the stackguard mailing list for the past couple of months.
And if you have any problems with this distro, the developers are all on the stackguard mailing list, and very responsive.
As for it not being a kernel hackers special I would dispute that, as I do all of my kernel work on this os
greg k-h
greg@(kroah|wirex).com
For the listeners tuning in at home, Linux now has the following Bluetooth stacks:
Now how am I supposed to get the Linux USB Bluetooth driver to play nice with all of these?
Well it could be worse, we could have no Bluetooth stacks for Linux at all!
Im excited about the USB interface...on Linux...
Take a look at the latest kernel, LOTS of USB devices are supported.
Will people STOP saying Linux does not have USB support! For the number of times I keep hearing it, I almost would start believing it, if I wasn't currently typing with my USB keyboard and using my USB HandSpring Visor docking station all the time...
Linux USB homepage
On a related note, some people just got the RIO MP3 player working with the Linux USB stack, take a look at http://rio500.sourceforge.net for more information on it.
Sorry to say, but the Symantic jobs in Eugene is for tech support only. Not really high tech. There are a few places in town, PSC Inc and there was Percon. They are both high tech embedded systems and application programming jobs with stable companies (PSC just bought Percon though).
The Hundai plant is manufacturing only, as is the HMT and Sony factories.
But don't get me wrong, it's a great town, and I'm glad I live here. Moved here from Pittsburgh too (keeping on topic) and glad I did.
There is a driver for acm USB modems in the current Linux 2.3.x kernel.
Please try it out, and let the developers know if you have any issues with it.
USB is up and running just fine in the 2.3.x series of kernels.
There is even a backport of the USB stack into 2.2.12 right here
Also check out the USB HowTO for getting started.
And the main Linux-USB page is www.linux-usb.org
Thank you for identifying your vested interest. That's all too rare around here.
No problem.
In other words: yes, Firewire will over the long term retain a significant raw-bandwidth advantage despite very short-term leapfrogging.
Correct. Firewire will probably always be faster. And it deserves to be that way. The USB group is only starting to work on the issues of higher speeds that Firewire solved a long time ago.
My question is: what speed issues did people have that would not have been adequately addressed by implementing both USB and Firewire? As many people including yourself have pointed out, there are still and will always be important differences between the two, and "one size fits all" is more often than not a lousy philosophy in computing.
I don't know. I think that this is more a political issue rather than a technical one.
I have nothing against USB in and of itself. My concern is that Firewire already exists and as near as I can tell already addresses the issues which USB2 seems to be trying to address (as compared to USB1). I happen to dislike reinvented wheels; I would have been much happier if the USB folks had let USB do what USB does best, and let Firewire do what Firewire does best, and go off to do other more useful things with their time. Competition is great, but there's plenty in both technical areas already. Pushing USB into the Firewire "problem space" is just an attempt by Intel to squash competition in the high-speed interconnect market by leveraging their position as the largest PC chipset manufacturer.
I agree.
It seems that Intel and other manufacturers are a little pissed about the licensing fees that go along with Firewire. So they bumped USB up to take care of the speed issues that were remaining with some devices (audio, mass storage, video). Now Intel can just implemement one chip on it's motherboards, and not have to worry about having to licensing money to anyone else.
I am remaining real sceptable. The rollout plan for operating system support, and silicon support is VERY aggressive. The hub model is VERY complex. True USB 2.0 support in both devices and hosts will be a number of years in the future.
Now does anyone have any ideas of what just happened to Device Bay (USB & Firewire working together)???
OK, I'm actually at the USB 2.0 Devcon right now, and have read the 2.0 proposed spec, so I'll take a stab at refuting these comments:
1.The usb.org article only claims "120-240Mbps". It's not clear where the ign.com article came up with 480Mbps.
The speed is 480Mbs. That is what the spec says.
2.Even if USB2 runs at 480Mbps, the Firewire folks aren't exactly standing still. Any raw bandwidth advantage of USB2 is sure to be short-lived at best.
Firewire and USB have too many things that are not in common, they really are not competitors. USB is aimed to be a PC centric bus. There has to be only one host, and a whole lot of clients. Firewire can be host to host. Firewire is more intrenched in the consumer electronic market, while USB is sticking to the PC (for now).
3.There's lots of blather in the USB2 announcement about supporting video cameras etc. but IIRC USB doesn't support the isochronous transfers which are usually considered necessary to serve those markets. Did I miss something?
You missed something. USB has always supported isochronous transfers. Look at the USB speakers from Philips for an example of a shipping product that uses this. Isochronous is still there for 2.0.
4.Another useful Firewire feature that USB doesn't seem to have is providing power through the same connector used for communications. Again, I may have missed it.
USB has ALWAYS supported power on the connector. How else does some of the devices work? 2.0 does not change this. It's still 5V at 100mA-500mA depending on what you need and ask for. If you need more power, take a look at the Plus Power Connector that IBM supports for USB. It can provide 12V or 24V at 3A. That's about all the current that anyone needs.
5.I don't remember how many devices USB supports, but I suspect it's less than Firewire.
USB supports 127 devices per host controller. You can plug in more than one host controller in your PC at a time. The record (I think) for most devices plugged in and working at once is around 144.
6.I know that USB-based host-to-host networking exists, but it's not clear to me whether it's really as well suited to that task as Firewire. In particular, I wonder how much asymmetry between hosts and devices (a la initiators and targets in SCSI) is built into the protocol, and how round-trip latency compares to other technologies.
As I said above, USB is a host-client bus. You can make (and buy) a device that does networking over USB from one computer to another, but this is just two client devices talking together in a box. Firewire can do true host to host on the bus itself. The USB protocol is a star topology with the PC host controller at the top. I can look up the round trip latency stuff somewhere, but it is built into the protocol, and the host and hub controllers seem to handle it well.
7.Similarly, I'd like seeing a comparison of how automagically reconfiguration happens when devices are added or removed using each technology.
I don't really know how Firewire does this at all, but USB handles this wonderfully. There is a description of how the protocol handles all of this in the spec (at www.usb.org).
In summary, USB 2.0 looks like it handles a lot of the speed issues that some people had with 1.1. It provides backward compatibility with all 1.1 and 1.0 devices and enables things like speakers and video cameras to run better.
Like it or not, USB looks to be here for a while. A lot of computers are coming out without a lot of different connectors, and USB is replacing them.
Ob Linux: USB is working on Linux in the 2.3.x series of kernels (it's also supported a little in the 2.2.x series, but not for many devices.) More information is at www.linux-usb.org