On Thu, Apr 14, 2011 at 11:01:36PM +0100, Alan Cox wrote: > > > 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 Meaning that you do not strongly object to keeping the muxing in kernelspace? > > > > > 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. Hm. That hadn't occured to me, and might be worth trying. > Alan -- elly -- 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
