From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756241Ab0IHBsW (ORCPT ); Tue, 7 Sep 2010 21:48:22 -0400 Received: from smtp109.sbc.mail.mud.yahoo.com ([68.142.198.205]:23233 "HELO smtp109.sbc.mail.mud.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751225Ab0IHBsU (ORCPT ); Tue, 7 Sep 2010 21:48:20 -0400 X-Yahoo-SMTP: fzDSGlOswBCWnIOrNw7KwwK1j9PqyNbe5PtLKiS4dDU.UNl_t6bdEZu9tTLW X-YMail-OSG: InkdezsVM1lpKDues9xUoXB7NNpqV3UCvNJoi.qeHasDJQA FnekD4jvm8.xCieIh5k6tKpD2wbHTxcgXMuocoWFf5claJYALeMRFLzr85N5 f6N6yHfGxTBotSsq_W_elwIbvxufv2Ji28xS97_1M5pmyubgGdmvycDVF2hb 7xMhCd15kuVWW9v3zXhwA9Uu4WwXdWQ_mM_ONjfITHkrZXWnqUluoER6bDh2 zs_u5lK3LmV7lsM7uuri3WDOjR9.y3oSWhlpN93NilONjgWmHz860Iu8R X-Yahoo-Newman-Property: ymail-3 Subject: Re: [RFC 04/22] tcm: Add v4 base data structures and struct target_core_fabric_ops From: "Nicholas A. Bellinger" To: Konrad Rzeszutek Wilk Cc: linux-scsi , linux-kernel , FUJITA Tomonori , Mike Christie , Christoph Hellwig , Hannes Reinecke , James Bottomley , Jens Axboe , Boaz Harrosh In-Reply-To: <201009071656.21568.konrad@darnok.org> References: <1283160040-6636-1-git-send-email-nab@linux-iscsi.org> <1283455187.5598.86.camel@haakon2.linux-iscsi.org> <1283644390.556.74.camel@haakon2.linux-iscsi.org> <201009071656.21568.konrad@darnok.org> Content-Type: text/plain Date: Tue, 07 Sep 2010 18:44:20 -0700 Message-Id: <1283910260.556.393.camel@haakon2.linux-iscsi.org> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2010-09-07 at 16:56 -0400, Konrad Rzeszutek Wilk wrote: > > Hi Konard, > > > > I just pushed most of your recommend cleanups for target_core_base.h to > > lio-core-2.6.git/lio-4.0. The cleanup series has been posted on > > lio-devel list to prevent extra noise on linux-scsi, et al, but for > > reference the shortlog and diffstat are attached below.. I did not dive > > into intermixed struct + #defines, but I am still pretty indifferent on > > this particular item. > > > > So the reasons why I thought it would be a good idea to combine the #defines > and the values and also dropping the prefix of structs for all of the 'flag' > members is that: > > 1) once you have them intermixed, searching for a particular flag either using > cscope/ctags becomes easier. You have the definition of the 'flag' and the > different values it can have in one localized spot. It also removes your > worry about the 'grep' - you usually search for the values that a specific > flag has and if you use that tool you can find it right there along with the > structure it was defined in. > > 2). From a perspective of a vendor maintainer who has to find a fix, getting > familiarized with the code within a short window time frame and having the > acceptable states and its definitions in one place (and even pointers to the > specs if there are some) makes it sooo much easier to grok the code. > Having even nice ascii art of how/what works together is even better. Ok, I think these are both reasonable points for combining the #defines near the structure members where they are actually used. I will go ahead and make this change, but I would still like to keep the exiting prefixes for structure members for now. Thanks for your comments Konrad! --nab