On Sun, Dec 28, 2008 at 09:47:47PM -0500, Martin Owens wrote: > Dear Greg, > > > Then do a simple s/proc/dev/ on $DEVICE in fxload and you will be fine, > > right? > > That's not a fix, it's a bad work-around. I'm shocked that a kernel > hacker of your seniority and experience could suggest such a terrible > fix. The data coming in is garbage, you can mitigate but you can't just > rewrite the data like that. WTF? The data coming in isn't "garbage", it is your distro that is "garbage". Your distro isn't mounting usbfs at the location it was originally designed for, so how would the kernel know otherwise? And yes, things have changed over the years to make sense not to mount usbfs in such a place, and I know and agree with those reasons why to not do that, but note that we can't change the kernel here, otherwise it would be a ABI breakage. Again, as the distro knows exactly where it is placing usbfs, it can handle this in userspace. Due to legacy concerns, the kernel can't change where it reports $DEVICE, or it might break code that has been working since the 2.2 days (yes, usbfs is old.) So you might want to rethink your above statement... > Last thing any distro needs is to weigh it's self down with patches that > can never be pushed upstream. We need this fix to work for everyone, > even if you take ubuntu and change the usbfs mount point. I'm saying do the change in userspace, as that knows where usbfs is mounted, the kernel doesn't know that. There is no kernel change needed. Once final time, if your distro mounts usbfs in a different location than /proc/bus/usb/ then your distro needs to handle all userspace programs changes that are expecting it to be mounted in that location. It's that simple. And it's not a kernel issue. thanks, greg k-h -- 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
