From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E1EAC433E0 for ; Wed, 8 Jul 2020 10:05:44 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1CFD2204EC; Wed, 8 Jul 2020 10:05:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="e9Yg7u+a"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="fX9lsDrF"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="O8OClbpM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1CFD2204EC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-1.v29.lw.sourceforge.com) by sfs-ml-1.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1jt6xR-000483-PF; Wed, 08 Jul 2020 10:05:41 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-1.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jt6xP-00045j-Ue for linux-f2fs-devel@lists.sourceforge.net; Wed, 08 Jul 2020 10:05:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=oJKfhpS2TAv3dfAMEih1hdrRNJEaMuKN0Xzg9BWeoSo=; b=e9Yg7u+aBgFflqQgzT4GWFiYym rULnohbwh80HYOv41rI0pZVmAxqIzyaFw5+hzqVmiIpvNFN++eKVbx8xe3jDSgDbEct0CmQsJCsOj LUDXk2O0OItsKVmdu3j4KRMpZvk50QX//nfqw/obAEru982PmiXZK1qr+4qE0/mwx6OM=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=oJKfhpS2TAv3dfAMEih1hdrRNJEaMuKN0Xzg9BWeoSo=; b=fX9lsDrFCERteebNLEi43SpVnE f1P0IFjW7OgqdfzlL4ukJy/qrtw4L7OxJISEh5Ac0Lj3TGXfDWe6KMq8XT0Zxg7N5MOuG7bKHa9XZ DRsgruovmMBe65qdithtGKaJ7T0QpSODNnitfrhV7F7EE0L9yYjvvcBtrbBDsgcliPmU=; Received: from mail.kernel.org ([198.145.29.99]) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1jt6xO-00B3dO-7O for linux-f2fs-devel@lists.sourceforge.net; Wed, 08 Jul 2020 10:05:39 +0000 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 Message-ID: <20200708100527.GA448589@kroah.com> References: <20200703065420.3544269-1-daeho43@gmail.com> <20200703141359.GA2953162@kroah.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Headers-End: 1jt6xO-00B3dO-7O Subject: Re: [f2fs-dev] [PATCH v3] f2fs: add symbolic link to kobject in sysfs X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Daeho Jeong , kernel-team@android.com, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net 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 _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5B2AC433DF for ; Wed, 8 Jul 2020 10:05:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7750F20775 for ; Wed, 8 Jul 2020 10:05:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594202733; bh=yTKUIgGMoXAh3uS6fiL+0DHrR3iq2vwf7Im4h1Eez5A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=qCQl4Tq0V8HVQyZEF/36SNpJGl+4IY9EY5+c5RQg5J8gKRIrglPyOJDKIFCiSvKNg VOnXVpMLSx2ed7DzaZLwLkrrZc+zRHbDw1vZMLE+Na66LntFaFWyl8iL6smVIFIJs5 nLCUuqUrlyR3fgglNbfvGx/pi8r0Dn/UpUvcNPUo= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728658AbgGHKFc (ORCPT ); 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