> > > So, to get the ball rolling, here are some factors that IMHO > > > help decide in which side to implement a driver: > > > > > > - if the driver ties a hardware device to an existing > > > in-kernel interface (network, block, serial, bluetooth, > > > video4linux, etc.), it should probably be implemented > > > in-kernel. > > > > Agreed, I think this is clear. > > Yes, this the primary decision point, everything after this depends on > lots of variables :)
Including a pragmatic concern: performance requirements. Today's usbfs-based userspace drivers don't get any zerocopy benefits. So if you're passing around enough data that your target environment needs a zerocopy I/O model (maybe it's got to run on an embedded system with a small battery and not much spare CPU power), that can argue in favor of a kernel driver. I don't know whether the "usbfs2" work addresses that issue. - Dave > Agreed. It all depends on the situation, we have kernel drivers for > devices that can be done in userspace, but not as cleanly or nicely, and > so, they stay as kernel drivers. > > In the end, it comes down to individual cases, so let's handle them at > that level, it's easier that way. - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
