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=-3.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 E792FC433DF for ; Tue, 18 Aug 2020 20:53:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id BB4A62063A for ; Tue, 18 Aug 2020 20:53:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597784015; bh=PoiM3j5EkvZ44e8I6cUQWHdTxb0lNwr5tUyBzR8juj0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=YZAySPv33fc46VpRO2UTtYvg8Q4HzcLhtOzmjEV31IM9d7SzbjW6+OaCeKNL41HA6 Y++aNshVNrYVIZjhmWdi5iHlcy4yOyDVsEdRRwS7dp9vDU522l6F0tNWxOCcIHXhFi A3LVkh7WGGAkC8fSDw6H89wtqRsEwb8N24I5H3Es= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726845AbgHRUxd (ORCPT ); Tue, 18 Aug 2020 16:53:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726829AbgHRUxc (ORCPT ); Tue, 18 Aug 2020 16:53:32 -0400 Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C6089C061343 for ; Tue, 18 Aug 2020 13:53:31 -0700 (PDT) Received: by mail-lj1-x244.google.com with SMTP id f26so22961141ljc.8 for ; Tue, 18 Aug 2020 13:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=44jjlz9gHZ8bxkxJCT+KFdrq1JkP5ys9BBa+Qk39NAU=; b=KmKfogzwUujvQb/F0JA/vopaWbvFysSlsxJrpItNo5RKDQ8MIZrythcEa0jhqcR97h 6k/jvzQGWfMSCchn3FxL3xWMnBP2o1wmrl8y6sRimpA8Bh+iDfzxbjypP5Ke/mhWrexJ Ac+8fu9qUv1fiSsbJIE2/XWj5iLbyNhOIcPwQ= 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=44jjlz9gHZ8bxkxJCT+KFdrq1JkP5ys9BBa+Qk39NAU=; b=XLkT+dkBX7MvTCzjO/GToOzmtt+k64Jh3Mw7yyYXVGEN2RlT6oX4APynEQbxtvhiQf ax0XhSvKBNOcOncFGmlQmbh0+K7Grh818/NhgZLRTtqbhStTUF/Bq0VKgsvUN/wpNKkf lR6MemYYDsB0jNqQoGtDrZrFpZD8H8FjzkL5OmgQdvmZAzGWL30XuIdCP+flmQHV9HTq rzBjkwp09IKaXMq+M5NvVm8PgH7MMQUP78W72TdCtF2XRMIGRnVFwpWpnqJ4FGcazu52 JFfVrT+OeGJYoWikE9wNUS2uJevjS904E1E4Yk/CpYxG/q7OTPNhrL+Mb+32Dl8k1c8t M5gA== X-Gm-Message-State: AOAM532WNyXmbLBgaOBfHA2OhgFOmbmqI71KadPRQqH+H0Q8Mn0aXc1V CFfUc/Z0we/pAq3Dsvpz4hjZT5X/12QliA== X-Google-Smtp-Source: ABdhPJwsI9pv4hBK67F116nO13zEnGbTc0Od0N2n86PQXSScBqsEmPXspbgsHcXn/ZgEYCgjo0v1rw== X-Received: by 2002:a2e:9ed4:: with SMTP id h20mr10663202ljk.82.1597784009868; Tue, 18 Aug 2020 13:53:29 -0700 (PDT) Received: from mail-lj1-f181.google.com (mail-lj1-f181.google.com. [209.85.208.181]) by smtp.gmail.com with ESMTPSA id f12sm6212072ljn.14.2020.08.18.13.53.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Aug 2020 13:53:28 -0700 (PDT) Received: by mail-lj1-f181.google.com with SMTP id v12so22968442ljc.10 for ; Tue, 18 Aug 2020 13:53:27 -0700 (PDT) X-Received: by 2002:a2e:b008:: with SMTP id y8mr9400093ljk.421.1597784007533; Tue, 18 Aug 2020 13:53:27 -0700 (PDT) MIME-Version: 1.0 References: <1842689.1596468469@warthog.procyon.org.uk> <1845353.1596469795@warthog.procyon.org.uk> <20200811135419.GA1263716@miu.piliscsaba.redhat.com> <52483.1597190733@warthog.procyon.org.uk> <066f9aaf-ee97-46db-022f-5d007f9e6edb@redhat.com> <94f907f0-996e-0456-db8a-7823e2ef3d3f@redhat.com> In-Reply-To: From: Linus Torvalds Date: Tue, 18 Aug 2020 13:53:11 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: file metadata via fs API To: Miklos Szeredi Cc: Steven Whitehouse , David Howells , linux-fsdevel , Al Viro , Karel Zak , Jeff Layton , Miklos Szeredi , Nicolas Dichtel , Christian Brauner , Lennart Poettering , Linux API , Ian Kent , LSM , Linux Kernel Mailing List 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 Tue, Aug 18, 2020 at 1:18 PM Miklos Szeredi wrote: > > So why mix a binary structure into it? Would it not make more sense > to make it text only? .. because for basic and standard stuff, the binary structure just makes sense and is easier for everybody. When I want to get the size of a file, I do "stat()" on it, and get the size from st.st_size. That's convenient, and there's no reason _not_ to do it. Returning the size as an ASCII string would be completely pointless and annoying as hell. So binary formats have their places. But those places are for standard and well-understood fields that are commonly accessed and do not have any free-form or wild components to them that needs to be marshalled into some binary format. Whenever you have free-form data, just use ASCII. It's what "mount" already uses, for chrissake. We pass in mount options as ASCII for a good reason. Basically, I think a rough rule of thumb can and should be: - stuff that the VFS knows about natively and fully is clearly pretty mount-agnostic and generic, and can be represented in whatever extended "struct statfs_x" directly. - anything that is variable-format and per-fs should be expressed in the ASCII buffer Look at our fancy new fs_context - that's pretty much what it does even inside the kernel. Sure, we have "binary" fields there for core basic information ("struct dentry *root", but also things like flags with MNT_NOSUID), but the configuration stuff is ASCII that the filesystem can parse itself. Exactly because some things are very much specific to some filesystems, not generic things. So we fundamentally already have a mix of "standard FS data" and "filesystem-specific options", and it's already basically split that way: binary flag fields for the generic stuff, and ASCII text for the odd options. Again: binary data isn't wrong when it's a fixed structure that didn't need some odd massaging or marshalling or parsing. Just a simple fixed structure. That is _the_ most common kernel interface, used for almost everything. Sometimes we have arrays of them, but most of the time it's a single struct pointer. But binary data very much is wrong the moment you think you need to have a parser to read it, or a marshaller to write it. Just use ASCII. I really would prefer for the free-form data to have a lot of commonalities with the /proc/mounts line. Not because that's a wonderful format, but because there are very very few truly wonderful formats out there, and in the absense of "wonderful", I'd much prefer "familiar" and "able to use common helpers" (hopefully both on the kernel side and the user side).. Linus