From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>
Cc: "Pali Rohár" <pali.rohar@gmail.com>,
"Andreas Dilger" <adilger@dilger.ca>,
"David Sterba" <dsterba@suse.com>,
"Darrick J. Wong" <darrick.wong@oracle.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: FS_IOC_GETFSLABEL and FS_IOC_SETFSLABEL
Date: Wed, 1 Jan 2020 13:10:54 -0500 [thread overview]
Message-ID: <20200101181054.GB191637@mit.edu> (raw)
In-Reply-To: <517472d1-c686-2f18-4e0b-000cda7e88c7@redhat.com>
On Tue, Dec 31, 2019 at 04:54:18PM -0600, Eric Sandeen wrote:
> > Because I was not able to find any documentation for it, what is format
> > of passed buffer... null-term string? fixed-length? and in which
> > encoding? utf-8? latin1? utf-16? or filesystem dependent?
>
> It simply copies the bits from the memory location you pass in, it knows
> nothing of encodings.
>
> For the most part it's up to the filesystem's own utilities to do any
> interpretation of the resulting bits on disk, null-terminating maximal-length
> label strings, etc.
I'm not sure this is going to be the best API design choice. The
blkid library interprets the on disk format for each file syustem
knowing what is the "native" format for that particular file system.
This is mainly an issue only for the non-Linux file systems; for the
Linux file system, the party line has historically been that we don't
get involved with character encoding, but in practice, what that has
evolved into is that userspace has standardized on UTF-8, and that's
what we pass into the kernel from userspace by convention.
But the problem is that if the goal is to make FS_IOC_GETFSLABEL and
FS_IOC_SETFSLABEL work without the calling program knowing what file
system type a particular pathname happens to be, then it would be
easist for the userspace program if it can expect that it can always
pass in a null-terminated UTF-8 string, and get back a null-terminated
UTF-8. I bet that in practice, that is what most userspace programs
are going to be do anyway, since it works that way for all other file
system syscalls.
So for a file system which is a non-Linux-native file system, if it
happens to store the its label using utf-16, or some other
Windows-system-silliness, it would work a lot better if it assumed
that it was passed in utf-8, and stored in the the Windows file system
using whatever crazy encoding Windows wants to use. Otherwise, why
bother uplifting the ioctl to one which is file system independent, if
the paramters are defined to be file system *dependent*?
- Ted
next prev parent reply other threads:[~2020-01-01 18:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-28 14:36 Pali Rohár
2019-12-28 19:14 ` Andreas Dilger
2019-12-28 20:05 ` Pali Rohár
2019-12-31 22:54 ` Eric Sandeen
2020-01-01 18:10 ` Theodore Y. Ts'o [this message]
2020-01-01 18:39 ` Pali Rohár
2020-01-02 21:57 ` Darrick J. Wong
2020-01-02 22:08 ` Pali Rohár
2020-01-07 23:15 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200101181054.GB191637@mit.edu \
--to=tytso@mit.edu \
--cc=adilger@dilger.ca \
--cc=darrick.wong@oracle.com \
--cc=dsterba@suse.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pali.rohar@gmail.com \
--cc=sandeen@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®