> > All of the above looks like things we don't want in the in-kernel driver > > anyway, right? > > I agree that all of the muxing stuff belongs entirely in userspace. It is > currently in kernelspace to support the closed userspace libraries. There are multiple ways to skin a cat > > > There's no requirement to support the closed userspace tool here, is > > there? If so, who is making that requirement? > > There is no requirement, but Google (and presumably others) are using it, and > breaking compatibility with it by changing the ioctl numbering seems like poor > form. That said, it would be nice if valgrind and similar could interpret these > ioctls. It's always been explicit kernel policy that any out of tree ABI isn't, in part to stop people trying to create stuff out of tree and ramming it down other folks throats. It adjusts the economics of the development model in the right direction. > > How would you feel about accepting both the current set of arbitrary values and > a set of new ioctls generated with the IOR/IOW macros? That would preserve > backwards compatibility until Google and others can move to an open set of > userspace libraries. The obvious question is how much of this stuff wants kicking into user space anyway. There is no rule against a driver that has sane ones and Google internally apply a tiddly patch to add the compat numbers for example. Alan -- 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
