From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752877AbeBSNkj (ORCPT ); Mon, 19 Feb 2018 08:40:39 -0500 Received: from mail-lf0-f52.google.com ([209.85.215.52]:33808 "EHLO mail-lf0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752666AbeBSNkg (ORCPT ); Mon, 19 Feb 2018 08:40:36 -0500 X-Google-Smtp-Source: AH8x2255YmlBvFdpMj5LQ7S6UftenvEtBcF3I2jOk+rcewhynQ/2kg7O60sik29+gefksNf2qWXhOw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: [PATCH 2/8] lightnvm: show generic geometry in sysfs From: =?utf-8?Q?Javier_Gonz=C3=A1lez?= X-Mailer: iPhone Mail (15D60) In-Reply-To: Date: Mon, 19 Feb 2018 14:40:32 +0100 Cc: Javier Gonzalez , "linux-block@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-nvme@lists.infradead.org" Message-Id: References: <1518530768-20956-1-git-send-email-javier@cnexlabs.com> <1518530768-20956-3-git-send-email-javier@cnexlabs.com> To: =?utf-8?Q?Matias_Bj=C3=B8rling?= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id w1JDep4B021488 >>> This breaks user-space. The intention is for user-space to decide >>> based on version id. Then it can either retrieve the 1.2 or 2.0 >>> attributes. The 2.0 attributes should not be available when a device >>> is 1.2. >>> >> Why does it break it? I'm only adding new entries. >> The objective is to expose the genneric geometry, since this is the >> structure that is passed on to the targets. Since some of the values are >> calculated, there is value on exposing this information, I believe. >> Another way of doing it, is adding the generic geometry at the target >> level, showing what base values it is getting, including the real number >> of channels/groups and luns/pus. >> Would this be better in your opinion? > > No. It should be one set of attributes for 1.2 (keep the way it is today), and then separate 2.0 attributes. User-space should then identify either by either 1 or 2 in the version attribute. > >>>> ... >>> csecs and sos are derived from the the generic block device data structures. >> As mentioned above, it is to represent the generic geometry. > > They are not part of the 2.0 spec. The fields can be derived from elsewhere. >>> Ok. Thanks for looking into it. Javier.