Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1097092imu; Wed, 16 Jan 2019 12:41:31 -0800 (PST) X-Google-Smtp-Source: ALg8bN6f1dIGR9YSY9xlpm3COVwWVKS6+Annj8IEwL2niP4g8SI52aK8T33pfhr89ZJS2S2A82kc X-Received: by 2002:a65:5bc4:: with SMTP id o4mr10709069pgr.426.1547671291744; Wed, 16 Jan 2019 12:41:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547671291; cv=none; d=google.com; s=arc-20160816; b=q394MQgXa5yNWnC+C/H7Tzi9vcxqapWWaR++0OSPB6VQw1nVczPpoc9iKy2pvfLI87 gFC7trVGPCEMNn8osLIlOLx/nOLjqeOkWm4F8t92FPvoVwR2knqgodF3fP+nPyxlmlZr Xk65dJCUJDwo3inA2loOWvTgk4itG2cUwPDggmkz9ERNNfdo3YqczIKrU5VXBBaZ5uDA RR9NqiJHHsv8RJf3CeVXP5kW5jU0FfOqLEkGfKbDhRlrUIQdooxw+6aDq7UCIlMtpIjh x+iIX4pPJ31FQzsSQgt6tl8aWhcVlIn95zmpPl8wop5KXEs0L83iHwohUc3ihaTGKWe+ 4Tgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:organization:from:subject:cc:to :dkim-signature; bh=Zz8m98MU4N2uGF+u5jyRhPDg9Shkpx1mVlDyrwF/fPU=; b=CbpuxfygDd/8QmtlkK/TivdWumuPvM5TC4oLTnSXxcjviYB7oPH9GvXoOPjILLBG6a PxFvjRwIjRluAept4L1f9ILfINDPWdUitXGUuW8yG509Heb2L7GoQ4h+TntT2PR2bgnL G8UDPuo+UdXYiwYHo6OmCyKEr1I3rVKGI7gflQInlUb7t7rlw4OswAfqglctzW3KewzZ o0PWPsNrMsMvekshDFQnNLXM12fHWKsGHDnH+U9waNI4KhzMG3IvZC5r7w5aIKLZSDGf 7xFIJUjUN+g5NOpcE7Xe8HeswJt+dy4OBzOGiKRVOeYCuyelqnU+C6SCghHIlXK0IXp7 6e1A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=EauE9qCQ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k18si7263471pfd.241.2019.01.16.12.41.16; Wed, 16 Jan 2019 12:41:31 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2018-07-02 header.b=EauE9qCQ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729840AbfAPCyc (ORCPT + 99 others); Tue, 15 Jan 2019 21:54:32 -0500 Received: from userp2120.oracle.com ([156.151.31.85]:33580 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727883AbfAPCyb (ORCPT ); Tue, 15 Jan 2019 21:54:31 -0500 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id x0G2n0IT059256; Wed, 16 Jan 2019 02:54:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=to : cc : subject : from : references : date : in-reply-to : message-id : mime-version : content-type; s=corp-2018-07-02; bh=Zz8m98MU4N2uGF+u5jyRhPDg9Shkpx1mVlDyrwF/fPU=; b=EauE9qCQc/LfVXMrB0SGFs93iQKmdYvqsRs9whM3rkzcBPZJ5wxtJ3OMBYOzbDnfCCRe 3mE+WKv9R5MwZvXLVrv2xZoTkooIA7C71OAknT93HTkQj6vKvpHji30ksq8LbCFdLzLR Z35WZSjQHQXFJO/sO9qdosriPAxYr90NlNWElbK+LSCPHn5sBKa2SOttNr6KguO4MlMT nYC6PTj//bxZvDyzExwKH6R4NV4Z5pMV5e4q7Ih33kQyiUFl8m+jFY8JeEaYQM7+tXCw VDOQfBetBbpD5/apmJ1aw9lR5MxJF2UNv4xCmhhLc46aCwFO4z+AwTuymrE2khH/VL6A cg== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2pybjs7buh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 16 Jan 2019 02:54:12 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x0G2s6fI012763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 16 Jan 2019 02:54:06 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x0G2s4Tc025392; Wed, 16 Jan 2019 02:54:05 GMT Received: from ca-mkp.ca.oracle.com (/10.159.214.123) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 15 Jan 2019 18:54:04 -0800 To: John Garry Cc: "Martin K. Petersen" , Christoph Hellwig , Logan Gunthorpe , , , , Intel SCU Linux support , Artur Paszkiewicz , "James E.J. Bottomley" , Jens Axboe , Jeff Moyer , chenxiang Subject: Re: [PATCH] scsi: isci: initialize shost fully before calling scsi_add_host() From: "Martin K. Petersen" Organization: Oracle Corporation References: <20190108205043.3122-1-logang@deltatee.com> <20190109184105.GB22070@lst.de> <8d96b40d-fc83-9218-9479-3de423594ddb@huawei.com> <0ffaf166-c7e5-b135-fdc5-bcac24148e62@huawei.com> Date: Tue, 15 Jan 2019 21:54:01 -0500 In-Reply-To: <0ffaf166-c7e5-b135-fdc5-bcac24148e62@huawei.com> (John Garry's message of "Mon, 14 Jan 2019 12:10:23 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9137 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=886 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901160020 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi John, >> So in this case I think that accessor functions are actually better >> because they allow us to print a big fat warning when you twiddle >> something you shouldn't post-initialization. So that's something I think >> we could--and should--improve. >> > Sure, this is an alternative, but I would rather make it obvious when > these parameters should be set so that this would not be required. I would like to have a mechanism in place that warns if you twiddle things that break assumptions made at host registration time. That's not a scenario the old registration interface was designed to handle. I am not sure I agree with your assertion that setting these masks in the struct prior to scsi_add_host() makes this ordering requirement much more obvious. It is not like you are passing in a list of parameters and then receiving a separately instantiated immutable scsi_host object. You are performing an operation on something you already have and own. That's why I commented that the current intersection between compile-time static host template, dynamically discovered pre-registration scsi_host parameters, and the registered runtime scsi_host struct is somewhat messy. Btw. I have no attachment to the prot wrappers whatsoever. The reason they exist is that the SCSI integrity support was optional. And therefore we had stub functions so things could be compiled without any of the integrity fields being present in the various SCSI structs. So I don't have any problem killing the wrappers except they may actually be handy for regressions like this one where you could #error if the driver writer violates the ordering requirement. -- Martin K. Petersen Oracle Linux Engineering