Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp417927ybt; Wed, 8 Jul 2020 03:09:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyZUC9Ny+ZSHfK0DxsP+cUyVKvMcJpLaMzu865liA3kMJXdcJ/M3i84y9Otj629N7g0tl+e X-Received: by 2002:a50:8fc4:: with SMTP id y62mr13365574edy.170.1594202970658; Wed, 08 Jul 2020 03:09:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594202970; cv=none; d=google.com; s=arc-20160816; b=RwwpsloqWU9DLfyj4dW/QCzElr2b3SQLgFiS4apUpMX6BvBhwD0OWC2rFKEf7qdgDd H4CLeY7t5kFGvJWBesTRPpURSvqIcHmXUNOpJxIEy+3eLwR03E79KABLtkgN0IsnO6pd CIq0gli6NWXPaP5N2WUwKmRhiZFbymgeXWSHHeLz3gj+Anmg8mir8WB4is1bkutsmj3K pg0tke/uMsQFvGtHUg0VId5GaNYA+G8wpBb6A61AkZuxMJieSP3iDAnKSCcIaLTlKPVV iczvGaNPRx1N4oDoPsM9GQk6m74GxgGo9egvXAKNZNJymNu038cLMSAeljEjjrc5fNpp uZOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=oJKfhpS2TAv3dfAMEih1hdrRNJEaMuKN0Xzg9BWeoSo=; b=GAOoSb2hU4wzPE/0ABBzI4E0mhrGYOP5PeUFHYOJoMmSrhIlY8kyiqdBQZM87RTlQ2 1UZOKvS+x+Q/GS/0N86HfgkV104mBjR2hLvI8rxQTjI2tZaOGPRfIoCtREb//lSTxn4n P5qECxX66RtnNNQgLGmQjalvSpcLsYXC7mQjcNT8sxJlgUWpX+7+MMxNWuDI4MTwYUud qBmQH8TnopaFs599FXLswWEdbdOqgj1xVpS9pjPWE06gbMMoIcxOZUUfmpYFKtIXXDc7 6R4EXObOlf1eQqdVq7Y474ZFUYlhOGNYnPrU9wx5KpegAEzUXqPX0cMp+S75rLbjVZut Zuag== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=O8OClbpM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c15si17613123edw.265.2020.07.08.03.09.07; Wed, 08 Jul 2020 03:09:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=O8OClbpM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728652AbgGHKFc (ORCPT + 99 others); Wed, 8 Jul 2020 06:05:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:56594 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726586AbgGHKFb (ORCPT ); Wed, 8 Jul 2020 06:05:31 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8B6CA204EC; Wed, 8 Jul 2020 10:05:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594202731; bh=yTKUIgGMoXAh3uS6fiL+0DHrR3iq2vwf7Im4h1Eez5A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=O8OClbpMbY9OCMuHPR8z/AuEAjgWpqOX7j8VzUdtfTaahbtr4MtPYKhaOBXiw6sg+ MWc3Jgcpu1fCrkNyH5b7QbY3pkYE3aNGJGn/l1f6N0H7EGaVSbdJjdk9D6xJg7dinV ecIALBSNJXAlmjN1/7LbgOjOH8YdGRKqMCebod6w= Date: Wed, 8 Jul 2020 12:05:27 +0200 From: Greg KH To: Daeho Jeong Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, kernel-team@android.com, Daeho Jeong Subject: Re: [PATCH v3] f2fs: add symbolic link to kobject in sysfs Message-ID: <20200708100527.GA448589@kroah.com> References: <20200703065420.3544269-1-daeho43@gmail.com> <20200703141359.GA2953162@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 06, 2020 at 08:47:07AM +0900, Daeho Jeong wrote: > > No Documentation/ABI/ entry for your new sysfs file/link? > > This is for adding a symbolic link to a pre-existed > /sys/fs/f2fs/ directory and it means /sys/fs/f2fs/ points > to /sys/fs/f2fs/. I already added the description of this in > Documentation/filesystems/f2fs.rst. Ok, but that's not the standard location for sysfs file documentation. > > And what does this help with? > > Some system daemons in Android access with the pre-defined sysfs entry > name in the json file. So whenever the project changes and the > partition layout is changed, we have to follow up the changes and > modify /sys/fs/f2fs/ name in the json file accordingly. That's what partition names are for, you should never depend on a "random number". > This will help them access all the f2fs sysfs entries consistently > without requiring to know those changes. No, please use a partition name, that is the only way to always know you are mounting the correct partition. You have created a random number here that might, or might not, change between boots depending on the order of the filesystem being mounted. It is not persistant or deterministic at all, please do not treat it as such. > > If it's really needed, why don't we do this for all filesystem types? > > This is for the daemon to change the mode of only F2FS with the power > hint of Android. Again, the point is that a filesystem type is not unique, this, if really really needed, should be an attribute for ALL filesystem types, f2fs is not special here at all. Please do not rely on this number ever being the same across boots, because your code is such that you can not guarantee that. And again, if you really want to know the partition you are mounting really is the partition you think you are mounting, use the partition label name, that is what it is there for, and is why we have been relying on that for decades. A new special per-filesystem-attribute that is semi-random is not the correct solution for the problem you are describing as far as I can determine. thanks, greg k-h