On Tue, 2010-08-24 at 18:41 +0400, Vladislav Bolkhovitin 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, we will write the compatibility module. It shouldn't take much time. > > But before we start, I'd like to clear 2 related questions: > > 1. How far the ABI compatibility "contract" goes? Are there cases, where > it isn't so strong? I'm asking, because I can recall that open-iscsi at > least once has broken ABI compatibility with user space tools. Was it an > accidental (but not corrected) mistake or was it deliberate? If the > latter, then, I guess, there must be some exceptions defining when ABI > compatibility can be not followed. I don't think it has to be complete. As long as the STGT people think it's good enough, that's fine by me. > 2. Currently STGT in the kernel is just 2 files, scsi_tgt_if.c and > scsi_tgt_lib.c (with headers), + ibmvstgt driver. The C files define the > STGT interface in question. So, if we keep ABI compatibility with the > new target engine, we would have to keep those 2 files included in the > kernel, This isn't really correct. The ABI is defined by the headers not the implementation. > which would effectively mean that STGT would stay in the kernel. > This would lead to the situation you are trying to avoid: 2 SCSI target > infrastructures in the kernel. Would it be OK? If you mean is the marketing solution of wedging two products into the kernel and calling it a single one going to fly, the answer is no. James -- 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
