From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [PATCH]QNX6 filesystem (RO) driver
Date: Thu, 16 Feb 2012 10:00:43 +0000
Message-ID: <20120216100043.GJ23916@ZenIV.linux.org.uk>
References: <4F29A37F.6070909@ontika.net>
 <20120212045629.GO23916@ZenIV.linux.org.uk>
 <4F3839CE.8040805@ontika.net>
 <20120212224358.GW23916@ZenIV.linux.org.uk>
 <4F3B1DD1.3000202@ontika.net>
 <20120215061012.GC23916@ZenIV.linux.org.uk>
 <20120215064728.GE23916@ZenIV.linux.org.uk>
 <20120215071119.GF23916@ZenIV.linux.org.uk>
 <20120215075750.GG23916@ZenIV.linux.org.uk>
 <20120215144037.GH23916@ZenIV.linux.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-fsdevel@vger.kernel.org
To: Kai Bankett <chaosman@ontika.net>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:42994 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750887Ab2BPKAq (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Thu, 16 Feb 2012 05:00:46 -0500
Content-Disposition: inline
In-Reply-To: <20120215144037.GH23916@ZenIV.linux.org.uk>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Wed, Feb 15, 2012 at 02:40:37PM +0000, Al Viro wrote:

> Other than that... this stuff could use some tidying up, but that's not
> a big deal.  I really wonder if these config options are worthwhile -
> might be better to stick endianness and mmi to y unconditionally.  And
> of course all those incrementals are completely untested and might very
> well br broken.

FWIW, having looked at that code again, I'm definitely in favour of dumping
the ENDIANNESS and MMI config options; the latter is not time-critical at all
(of anything even remotely hot it only affects the checksum verification
for longnames on readdir *and* its only effect is possible short-circuiting
a relatively long calculation - I've just spotted and fixed a braino in
that ifdef from hell, BTW).  And the former... I would be _very_ surprised
if disabling it would be a visible win on any workloads.

BTW, reporting non-options in ->show_options() is probably a bad idea;
sure, you end up ignoring options in your ->mount(), so it won't confuse
any userland scripts too badly, but...