Yes, this is something that I've been thinking about the last couple of days. Thunderbolt doesn't seem to be a complete protocol stack like USB - at least that'

Yes, this is something that I've been thinking about the last couple of days. Thunderbolt doesn't seem to be a complete protocol stack like USB - at least that's what Intel's emphasis on Thunderbolt's PCIe protocol implies. Rather, it seems to have a simple encapsulation protocol. Without a protocol stack you can't have stuff like class drivers or channel categories (bulk, isochronous, etc). Not unless you re-use another protocol or technology that also uses PCIe, like USB EHCI or something. But then what does the EHCI talk to over the Thunderbolt-PCIe? An EHC? Where? On the Thunderbolt device? In the Thunderbolt cable? Or is the EHCI reprogrammed to include a software EHC? Maybe that's what how Thunderbolt will work - re-implement every hardware bus controller (SATA, USB, etc) in software. A peripheral plugged into a Thunderbolt port on a computer would be either - A peripheral with a Thunderbolt connector itself, connected with a Thunderbolt-to-Thunderbolt cable. The peripheral would actually be communicating Thunderbolt-encapsulated USB packets (or SATA or whatever) with a software USB EHC in the computer. - A legacy peripheral (USB/SATA/whatever) connected with an expensive Thunderbolt-to-USB cable. The cable would have to do the Thunderbolt encapsulation and transcoding for the peripheral. Again, it would be communicating with a software USB EHC in the computer. I can kind of understand why Intel would be interested in this. If doing anything useful over Thunderbolt means implementing existing hardware controllers in software (SATA HBA, USB EHC, etc), Thunderbolt is going to be a great way of burning excess CPU cycles. Just as USB was a less CPU-efficient connector than Firewire, Thunderbolt may need even more CPU cycles. This would be a great technology to promote if you're in the business of selling people CPU cycles.