lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C73DA15.2010207@vlnb.net>
Date:	Tue, 24 Aug 2010 18:41:25 +0400
From:	Vladislav Bolkhovitin <vst@...b.net>
To:	James Bottomley <James.Bottomley@...e.de>
CC:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
	Dirk Meister <dmeister@...-paderborn.de>,
	linux-scsi@...r.kernel.org, Chetan Loke <chetanloke@...il.com>,
	Chetan Loke <generationgnu@...oo.com>,
	scst-devel <scst-devel@...ts.sourceforge.net>,
	linux-kernel@...r.kernel.org, Mike Christie <michaelc@...wisc.edu>
Subject: Re: [Scst-devel] Fwd: Re: linuxcon 2010...

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.

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, 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?

Thanks for (eventually!) defining clear rules and removing confusions!

Vlad
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ