On Tuesday 24 August 2010 10:51:04 Chris Weiss wrote: > On Tue, Aug 24, 2010 at 9:41 AM, Vladislav Bolkhovitin <vst@xxxxxxxx> wrote: > > James Bottomley, on 08/22/2010 12:43 AM wrote: > >> Interface re-use (or at least ABI compatibility) is the whole point, > >> it's what makes the solution a drop in replacement. > > > > I see now. You want ABI compatibility to keep the "contract" that no > > kernel changes can break applications binary compatibility for unlimited > > time. > > ok now I'm confused, or maybe I'm not understanding ABI correctly, or > maybe you guys are using it in a way that is inconsistent with popular You are thinking of the KABI. That changes per each release except if you buy a vendor product. Red Hat for example keeps an KABI symbol list where they guarantee that those parameters, structures ,etc will never change. John Masters wrote a nice paper about how they solved this: http://dup.et.redhat.com/presentations/DriverUpdateProgramTechnical.pdf I don't have experience with other vendors. In terms of ABI, think ioctl calls and its a parameters. They are suppose to stay the same for long long durations. > convention. As a VMware user, I have experienced fully that the > kernel ABI changes in various places with every release. VMwares > drivers have to be constantly updated to match changes in kernel > function parameters and even what functions are available. > > I've also experienced it with scsi cards, dsl modems, and other 3rd > party drivers. It's the one big downside to developing for the Linux > kernel, the ABI is /always/ changing. > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
