Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp34632imm; Tue, 17 Jul 2018 13:25:10 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfrXZwKxmRnwKsGips4Vaml/6cmbNP13SpQfAYJ3QyAJi0x2yK/Whvz9UreT5kVuN3/onfA X-Received: by 2002:a65:4249:: with SMTP id d9-v6mr2992418pgq.362.1531859110127; Tue, 17 Jul 2018 13:25:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531859110; cv=none; d=google.com; s=arc-20160816; b=gzAwfU/Yi9TUoJrpGU+rD0iCLoO/zNcijzDfUTP3JkKqyDVFGtAi23PWLs5kVpv7m4 lN/c8PsdeeqVdAXr+1mVGlCczrJCA6JeHj63D1iUSiNbwUgthjLI7PI4qtGvpAYG/UwM HsNgm/tpSbJqGIFoYWl4ElTtZOw7rOC1GaD8MPxDRKHlxrUGVfn5o5F6UivGj5rCvgOk /O9Qqf15c8TrifZXQMzgajg3cQbfo2DUegT1cMIKSvADdDRJGmGq3Yx6W5JtMGTEqaz9 ajZXPsBcfWyCDTSBnF3/YZtsHLGIO5Wq6v8+mpLUfIzo+eEet5Jrp+m8cP+fZBpUgEHV 6S9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=JM9XbvE+zDLC+PJHHQcAAA4nSmIKUx3AIK/gbccPAdY=; b=yhR+V7UoV3BKSNdMcKdKYXjOU5Np5XfFadjx1yZodfsieSaLHF6jsbs3+dOch/jXYx EVlGLPmGlGIYeVx+8cR1ROVEutlG6ETgaoJ7/IAX5KAbzTLvc8B4JY6vSKbaBfxIdzAa LLLkFhP/Tj/Izt+XwhSzAx2lMgq7rPbnzOXjyfvUGWLUG6V7j7KVRpF7SVnyZsgQA3Sn PeLHAZwr2r9fr7JwMsjXrn+boGK0G+/CaNRMBY8SDThQ2QPOGLiLf6ExtpYL1ld05UhC Q69ZrB6XaLdN9U4gnpws1TOkeHp5M/F9VEqh3ta2owXf8Va83c8weFz1EBpfuHoOkNF1 EYKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=V+DycCNE; 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=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y11-v6si1514297plk.6.2018.07.17.13.24.54; Tue, 17 Jul 2018 13:25:10 -0700 (PDT) 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=@chromium.org header.s=google header.b=V+DycCNE; 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=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730238AbeGQU6d (ORCPT + 99 others); Tue, 17 Jul 2018 16:58:33 -0400 Received: from mail-lf0-f68.google.com ([209.85.215.68]:40608 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729713AbeGQU6d (ORCPT ); Tue, 17 Jul 2018 16:58:33 -0400 Received: by mail-lf0-f68.google.com with SMTP id y200-v6so1784841lfd.7 for ; Tue, 17 Jul 2018 13:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JM9XbvE+zDLC+PJHHQcAAA4nSmIKUx3AIK/gbccPAdY=; b=V+DycCNE9pS+AVZe36Gh8G22wciyXFdQdCp20Z5D3kybMsvEdExbG1iiKX1bV5KI4y T25hRFZS3BzY9uWN9Ola+KFxlPVC8rgXN1Bxb9haECFruE1BaFFsxwwYW5cD5c0jjX3k Uw9FRbw8JXr1hdOJRqntxoA2GX1TBz6RUwVSY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JM9XbvE+zDLC+PJHHQcAAA4nSmIKUx3AIK/gbccPAdY=; b=UnPo0gHle/4LhiX67VzvFoFVQ8Qg6ublzr/DH/TpoP1rfjCNlZm0MiSjMHuxO+SMpW ypb0xGiTgn/HDCyTez27Gv8nxa5LPITdjmlD6Z3PTs/paZFEGv5RE8wg6GV2KA79ck7H sJ3qibH9bLqQaDKPos9LdyTo/4EGa0+UyGoV/5NXdLy69dwqYElWBCil7iM5Y6IgpvMM RpxUw64E+gEQVt16zUec95hGU7w8DyY5vVBo3yz/ETBxpi9ehPMsZKHzWt26FSrrzL86 BU3zF93KtsNudM9+p8dyQmVCBiHPXV4h100p7roIRmNWrrCZGXwt4e+jw5oaWAkEfvU0 Q15g== X-Gm-Message-State: AOUpUlElDCWnSMvUOgs8SHYLE3bFTeX53UrNo3BEivmsw2E8QvyaPCC9 AoVHVo3KpzMT26d1QgjNkoOsS84sKDk= X-Received: by 2002:a19:f70d:: with SMTP id z13-v6mr2085063lfe.33.1531859053647; Tue, 17 Jul 2018 13:24:13 -0700 (PDT) Received: from mail-lf0-f53.google.com (mail-lf0-f53.google.com. [209.85.215.53]) by smtp.gmail.com with ESMTPSA id n17-v6sm294199ljb.82.2018.07.17.13.24.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jul 2018 13:24:12 -0700 (PDT) Received: by mail-lf0-f53.google.com with SMTP id j8-v6so1787181lfb.4 for ; Tue, 17 Jul 2018 13:24:12 -0700 (PDT) X-Received: by 2002:a19:10c4:: with SMTP id 65-v6mr2258198lfq.113.1531859052137; Tue, 17 Jul 2018 13:24:12 -0700 (PDT) MIME-Version: 1.0 References: <1530858040-13971-1-git-send-email-sayalil@codeaurora.org> <1530858040-13971-3-git-send-email-sayalil@codeaurora.org> <0dce9e9c-4f93-9857-72ee-f65ff195c41a@codeaurora.org> <4cb931e199599314829f5ff750797c88fc123f1f.camel@wdc.com> In-Reply-To: <4cb931e199599314829f5ff750797c88fc123f1f.camel@wdc.com> From: Evan Green Date: Tue, 17 Jul 2018 13:23:35 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH V5 2/2] scsi: ufs: Add configfs support for ufs provisioning To: Bart.VanAssche@wdc.com Cc: sayalil@codeaurora.org, Vinayak Holikatti , linux-kernel@vger.kernel.org, asutoshd@codeaurora.org, riteshh@codeaurora.org, cang@codeaurora.org, martin.petersen@oracle.com, subhashj@codeaurora.org, linux-scsi@vger.kernel.org, vivek.gautam@codeaurora.org, Rajendra Nayak , jejb@linux.vnet.ibm.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 16, 2018 at 5:04 PM Bart Van Assche wrote: > > On Mon, 2018-07-16 at 16:46 -0700, Evan Green wrote: > > I see Bart has chimed in on the next series with a suggestion to break > > out each field into individual files within configfs. Bart, what are > > your feelings about converting to a binary attribute? I remember when > > I did my sysfs equivalent of this patch, somebody chimed in indicating > > a "commit" file might be needed so that the new configuration could be > > written in one fell swoop. One advantage of the binary attribute is > > that it writes the configuration atomically. > > Hello Evan, > > I may be missing some UFS background information. But since a configfs interface > is being added I think the same rule applies as to all Linux kernel user space > interfaces, namely that it should be backwards compatible. Additionally, if > anyone ever will want to use this interface from a shell script, I think that > it will be much easier to write multiple ASCII attributes than a single binary > attribute. > Hi Bart, I'm unsure about the compatibility aspect for binary attributes that essentially represent direct windows into hardware. I suppose this comes down to who this interface is most useful to. Hypothetically lets say a future revision of UFS adds fields to the configuration descriptor, but is otherwise backwards compatible. If this interface is primarily for OEMs initializing their devices in the factory, then I'd argue they'd want the most direct window to the configuration descriptor. These folks probably just have a configuration they want to plunk into the hardware, and would prefer being able to write all fields over having some sort of compatibility restriction. If, on the other hand, this is used by long-running scripts that stick around for years without modification, then yes, it seems like it would be more important to stay compatible, and have smarts in the kernel to make writes of old descriptors work in new devices. At least for myself, I fall into the category of someone who just needs to plunk a configuration descriptor in once, and would prefer not to have to submit kernel changes if the descriptor evolves slightly. It also seemed a little odd that this patch now spends a bunch of energy converting ASCII into bytes, just to write it without modification into the hardware, and convert back again to ASCII for reads. We plan to use a script for provisioning, and could easily handle ASCII or rawbytes: # Some bytes, ready to go with the interface today... some_bytes="00 01 02 03" # Same bytes, now in binary format bytes_fmt=$(echo " $some_bytes" | sed 's/ /\\x/g') /usr/bin/printf "$bytes_fmt" > /configfs/ufs_provision I'm not dead set on binary, since as above I could do it either way, but it seemed worth at least talking through. Let me know what you think. -Evan