From mboxrd@z Thu Jan  1 00:00:00 1970
From: Gerd Hoffmann <kraxel@suse.de>
Subject: Re: [patch/rfc] multiprotocol blkback drivers (32-on-64)
Date: Tue, 19 Dec 2006 09:20:38 +0100
Message-ID: <4587A0D6.1080108@suse.de>
References: <4586C426.8050101@suse.de> <4586D974.76E4.0078.0@novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xensource.com>
In-Reply-To: <4586D974.76E4.0078.0@novell.com>
List-Unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xensource.com>
List-Help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-Subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
Sender: xen-devel-bounces@lists.xensource.com
Errors-To: xen-devel-bounces@lists.xensource.com
To: Jan Beulich <jbeulich@novell.com>
Cc: Xen devel list <xen-devel@lists.xensource.com>
List-Id: xen-devel@lists.xenproject.org

Jan Beulich wrote:
> I understand you favor this over the bi-modal approach I took? Any specific
> advantages? Jan

IMHO the code is more readable and I'd rate the chance to be accepted by
lkml review higher.  I don't like the approach to hide alot of the logic
in preprocessor magic.

It leaves the door open to add more protocols.  Not that I see a need
right now.  But maybe the lkml folks ask us to consolidate to some
struct layout which doesn't look different on different architectures
(i.e. sort struct members by size), then we maybe have to support a
third protocol ...

cheers,
  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>