From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750873AbdA2Jqn (ORCPT ); Sun, 29 Jan 2017 04:46:43 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:33238 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750785AbdA2Jqm (ORCPT ); Sun, 29 Jan 2017 04:46:42 -0500 Date: Sun, 29 Jan 2017 00:56:10 -0800 From: Christoph Hellwig To: KY Srinivasan Cc: Christoph Hellwig , Cathy Avery , Haiyang Zhang , "jejb@linux.vnet.ibm.com" , "martin.petersen@oracle.com" , "dan.carpenter@oracle.com" , "devel@linuxdriverproject.org" , "linux-kernel@vger.kernel.org" , "linux-scsi@vger.kernel.org" , "famz@redhat.com" Subject: Re: [PATCH v2 0/2] scsi: storvsc: Add support for FC lightweight host. Message-ID: <20170129085610.GA10258@infradead.org> References: <1485437940-18706-1-git-send-email-cavery@redhat.com> <20170126145159.GA29683@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Jan 29, 2017 at 12:35:32AM +0000, KY Srinivasan wrote: > Windows has chosen this model for virtualizing FC devices to the guest - > without rports (or vports). As I noted in my earlier email, James came > up with this notion of a lightweight template almost a year ago. We can > certainly pick a more appropriate name and include better documentation. Can we take a step back and figure out what you're trying to archive here. storsvc is a paravirtualized device interface, and whatever underlies it should be of no relevance for the guest. Despite that fact Microsoft apparently wants to expose a FC-like port_name and node_name to guests for some virtual disks. Can you please explain what the guest is supposed to use them for? And second I'd like to understand what the fascination with the FC transport class is to expose these two attributes. Given that your sysfs layout will be entirely different from real FC devices I simply don't see any need for that. Why can't this whole thing simply be solved by adding sdev_attrs for the port_name and node_name to storsvc directly?