On Thursday 09 June 2011 22:18:28 Timur Tabi wrote: > > More importantly, the code you have chose (0) conflicts with existing drivers > > (frame buffer, scsi and wavefront among others). Please chose a free one and > > add it to Documentation/ioctl/ioctl-number.txt in the same patch. > > Ok, I was really hoping to avoid doing this. Like I said, binary compatibility > is important, and changing the type will break my existing apps. Are you > insisting that I pick a new number? I definitely insist that you have a proper interface in the driver at the time that it gets merged, and that probably includes a collision-free ioctl code. You can probably make the driver support both the traditional and the new interface, but I would prefer if you kept that as a private patch on top a clean kernel driver. It's also a good idea to keep the header file clean and only define the new interface there, to ensure that all applications that are built in the future have to use the new interface. When you make the patch to add backwards compat support, just add it to the driver itself, not to the header. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-console" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
