Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp4391972ybb; Tue, 14 Apr 2020 06:28:21 -0700 (PDT) X-Google-Smtp-Source: APiQypJvuy7uxtFVgqHxG05J2rfwkK3swQjclovzCRTHZe/ipj63t2nevwtXFDMpu9ExPv1kHwEZ X-Received: by 2002:a17:906:a2d3:: with SMTP id by19mr89281ejb.370.1586870900890; Tue, 14 Apr 2020 06:28:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586870900; cv=none; d=google.com; s=arc-20160816; b=iFZxGBUGHb6fddQZQtsJHyMZ4vZ2fP6JDkgyQYlWjlKOw9II3mxvbedfJVxqL/68T2 bjvAzz7DQrElKKlfwfAc1QcRRcE71N/n9Wpij4B3kH5k71YZQYHBsWibcGxqw9CX5aLt yDuHV9Vy435ANxSmyoYLsTQfhsFxYkhRaM1mh5QHo+Jn9J8ITNlODGKy4Udo4nxPJz9/ WIAMOHYbQZrZR8uMkczq3S3++STG72/bw8hO/YwirhG4fkMXZuGty5GiZogDPUmU86aX m2+2L+4DW1V1XW6K/UfTuQWyOu0hbrzY9uBqYRYGxacMrQT8wAjOFgyzqZnqwGPMMEvs VnOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:organization:references:in-reply-to:date:cc:to:from :subject:message-id; bh=BNw7EHF4N+mmi79uM8Sk5GXeVHHB5x/dO0C8voE06yM=; b=gnod8ZtBORysqq0hJGJ2tAkBc1gFxncbP3OaWf82Ph0h/sh4ya7bPa0bEeKDjQAuDy kWYHlvJjt9SDHW2M50HCdMQID/PEoIHdvbc+OpHmCi/S/e+3SqTX28jcWAfT260Np+O0 mGjisTKrGz39GvrF9Rqv28Yt/buYSWtsyFqnCKYvpW/8tq5Ah8bu0ZCzsVzt5SRw6lUB 2E7RSb+qTdsYMC0929QJ29ZbhILizAZHeFZmepYdNPJOViiYXhjtZsSeb5npcpEY0ijr hEFcsNbqWoKIETX47bAHbG8gwoEIw6QLbBJaXtWj9uiLlJ3iKc/v0JhcCAPq/voqKurP s9yw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l22si8316492ejg.362.2020.04.14.06.27.56; Tue, 14 Apr 2020 06:28:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387449AbgDMRu0 (ORCPT + 99 others); Mon, 13 Apr 2020 13:50:26 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:33100 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387436AbgDMRuZ (ORCPT ); Mon, 13 Apr 2020 13:50:25 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: ezequiel) with ESMTPSA id 797372A0A5B Message-ID: <2672d7de2033fa14b9835b17b6fc59ba2cc4cd14.camel@collabora.com> Subject: Re: [PATCH v2] unicode: Expose available encodings in sysfs From: Ezequiel Garcia To: Gabriel Krisman Bertazi , linux-fsdevel@vger.kernel.org Cc: linux-ext4@vger.kernel.org, kernel@collabora.com, Theodore Ts'o , Jaegeuk Kim Date: Mon, 13 Apr 2020 14:50:13 -0300 In-Reply-To: <20200413165352.598877-1-krisman@collabora.com> References: <20200413165352.598877-1-krisman@collabora.com> Organization: Collabora Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.0-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Hey Gabriel, On Mon, 2020-04-13 at 12:53 -0400, Gabriel Krisman Bertazi wrote: > A filesystem configuration utility has no way to detect which filename > encodings are supported by the running kernel. This means, for > instance, mkfs has no way to tell if the generated filesystem will be > mountable in the current kernel or not. Also, users have no easy way to > know if they can update the encoding in their filesystems and still have > something functional in the end. > > This exposes details of the encodings available in the unicode > subsystem, to fill that gap. > > Cc: Theodore Ts'o > Cc: Jaegeuk Kim > Signed-off-by: Gabriel Krisman Bertazi > > --- > Changes since v1: > - Make init functions static. (lkp) > > Documentation/ABI/testing/sysfs-fs-unicode | 13 +++++ > fs/unicode/utf8-core.c | 64 ++++++++++++++++++++++ > fs/unicode/utf8-norm.c | 18 ++++++ > fs/unicode/utf8n.h | 5 ++ > 4 files changed, 100 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-fs-unicode > > diff --git a/Documentation/ABI/testing/sysfs-fs-unicode b/Documentation/ABI/testing/sysfs-fs-unicode > new file mode 100644 > index 000000000000..15c63367bb8e > --- /dev/null > +++ b/Documentation/ABI/testing/sysfs-fs-unicode > @@ -0,0 +1,13 @@ > +What: /sys/fs/unicode/latest > +Date: April 2020 > +Contact: Gabriel Krisman Bertazi > +Description: > + The latest version of the Unicode Standard supported by > + this kernel > + Missing stop at the end of the sentence? > +What: /sys/fs/unicode/encodings > +Date: April 2020 > +Contact: Gabriel Krisman Bertazi > +Description: > + List of encodings and corresponding versions supported > + by this kernel Ditto. > diff --git a/fs/unicode/utf8-core.c b/fs/unicode/utf8-core.c > index 2a878b739115..b48e13e823a5 100644 > --- a/fs/unicode/utf8-core.c > +++ b/fs/unicode/utf8-core.c > @@ -6,6 +6,7 @@ > #include > #include > #include > +#include > > #include "utf8n.h" > > @@ -212,4 +213,67 @@ void utf8_unload(struct unicode_map *um) > } > EXPORT_SYMBOL(utf8_unload); > > +static ssize_t latest_show(struct kobject *kobj, > + struct kobj_attribute *attr, char *buf) > +{ > + int l = utf8version_latest(); > + > + return snprintf(buf, PAGE_SIZE, "UTF-8 %d.%d.%d\n", UNICODE_AGE_MAJ(l), > + UNICODE_AGE_MIN(l), UNICODE_AGE_REV(l)); > + > +} > +static ssize_t encodings_show(struct kobject *kobj, > + struct kobj_attribute *attr, char *buf) > +{ > + int n; > + > + n = snprintf(buf, PAGE_SIZE, "UTF-8:"); > + n += utf8version_list(buf + n, PAGE_SIZE - n); > + n += snprintf(buf+n, PAGE_SIZE-n, "\n"); > + I was wondering how sysfs-compliant this was, in terms of one value per attribute. Although, we do seem to break this on a few cases. > + return n; > +} > + > +#define UCD_ATTR(x) \ > + static struct kobj_attribute x ## _attr = __ATTR_RO(x) > + > +UCD_ATTR(latest); > +UCD_ATTR(encodings); > + > +static struct attribute *ucd_attrs[] = { > + &latest_attr.attr, > + &encodings_attr.attr, > + NULL, > +}; > +static const struct attribute_group ucd_attr_group = { > + .attrs = ucd_attrs, > +}; > +static struct kobject *ucd_root; > + > +static int __init ucd_init(void) > +{ > + int ret; > + > + ucd_root = kobject_create_and_add("unicode", fs_kobj); > + if (!ucd_root) > + return -ENOMEM; > + > + ret = sysfs_create_group(ucd_root, &ucd_attr_group); > + if (ret) { > + kobject_put(ucd_root); > + ucd_root = NULL; > + return ret; > + } > + > + return 0; > +} > + > +static void __exit ucd_exit(void) > +{ > + kobject_put(ucd_root); > +} > + > +module_init(ucd_init); This code is not a module, so how about fs_initcall? > +module_exit(ucd_exit) > + I can be wrong, but I see no way to remove it :-) Thanks, Ezequiel