On Thu, 29 Jan 2009, David Vrabel wrote: > Alan Stern wrote: > > > > Pushing scatterlists down to the HCD level would involve several > > nontrivial changes to the code. The issue of the buffer lengths is > > just one of them, although it is perhaps the most vexing. > > I don't see where the complexity is. The HCD simply fills the > hardware's s-g list structures based on the s-g list in the URB. I didn't say it was complex; I said it was nontrivial. That's because the existing HCD code is already complicated and difficult to decipher. > Obviously, none of the existing HCDs can support s-g lists in this > manner and should continue to only accept URBs without s-g lists. It's a little difficult to comprehend the intent behind this statement. Here's a sort of flow-of-consciousness account of the reactions it provoked in me: Is it really obvious that none of the existing HCDs can support s-g lists in this manner? Yes, it's _true_, but that's not the same as being _obvious_. I guess it is obvious to most people reading this email -- but to us it's _so_ obvious there's no point stating it. After all, why else would we be having this discussion? The grammar is also a little puzzling. "... none of the existing HCDs ... should continue to only accept URBs without s-g lists." Does that mean all of the existing HCDs should stop only accepting URBs without s-g lists? Not to mention the fact that all URBs are without s-g lists -- there's no such thing as an URB with an s-g list! And then what about "only accepting"? Does that mean the HCDs should start doing something else with these URBs besides accepting them? Are you saying that if somebody does implement s-g lists for URBs, none of the existing HCDs should be changed to accept them? In that case, what use would they be? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
