LKML Archive on lore.kernel.org
 help / color / Atom feed
From: "Pali Rohár" <pali.rohar@gmail.com>
To: Sasha Levin <sashal@kernel.org>
Cc: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	devel@driverdev.osuosl.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"Sasha Levin" <alexander.levin@microsoft.com>,
	"Christoph Hellwig" <hch@infradead.org>
Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to staging
Date: Fri, 30 Aug 2019 09:56:47 +0200
Message-ID: <20190830075647.wvhrx4asnkrfkkwk@pali> (raw)
In-Reply-To: <20190829233506.GT5281@sasha-vm>

Hello, thank you for input!

On Thursday 29 August 2019 19:35:06 Sasha Levin wrote:
> On Thu, Aug 29, 2019 at 07:18:16PM -0400, Valdis Klētnieks wrote:
> > On Thu, 29 Aug 2019 22:56:31 +0200, Pali Roh?r said:
> > 
> > > I'm not really sure if this exfat implementation is fully suitable for
> > > mainline linux kernel.
> > > 
> > > In my opinion, proper way should be to implement exFAT support into
> > > existing fs/fat/ code instead of replacing whole vfat/msdosfs by this
> > > new (now staging) fat implementation.
> > 
> > > In linux kernel we really do not need two different implementation of
> > > VFAT32.
> > 
> > This patch however does have one major advantage over "patch vfat to
> > support exfat" - which is that the patch exists.
> > 
> > If somebody comes forward with an actual "extend vfat to do exfat" patch,
> > we should at that point have a discussion about relative merits....
> 
> This patch going into staging doesn't necessarily mean that one day
> it'll get moved to fs/exfat/. It's very possible that the approach would
> instead be to use the staging code for reference, build this
> functionality in fs/fat/, and kill off the staging code when it's not
> needed anymore.

So, if current exfat code is just going to be "reference" how to
implement exfat properly in fs/fat, is this correct usage of "staging"?

I was in impression that staging is there for drivers which needs
cleanup as they are not ready to be part of mainline. But not that it is
for "random" implementation of something which is going to be just a
"code example" or "reference" for final implementation which would be
different.

Maybe other people could clarify state of staging, if this is how
staging should be used or not.

> With regards to missing specs/docs/whatever - our main concern with this
> release was that we want full interoperability, which is why the spec
> was made public as-is without modifications from what was used
> internally. There's no "secret sauce" that Microsoft is hiding here.

Ok, if it was just drop of "current version" of documentation then it
makes sense.

> How about we give this spec/code time to get soaked and reviewed for a
> bit, and if folks still feel (in a month or so?) that there are missing
> bits of information related to exfat, I'll be happy to go back and try
> to get them out as well.

Basically external references in that released exFAT specification are
unknown / not released yet. Like TexFAT. So if you have an input in MS
could you forward request about these missing bits?

Also, MS already released source code of FAT32 kernel driver
(fastfat.sys) and from code can be seen that it does not match MS FAT
specification, and include some "secret sauce" bits. Source code is on:
https://github.com/microsoft/Windows-driver-samples/tree/master/filesys/fastfat

In fastfat.sys there is e.g. usage of undocumented bits in directory
entry or usage of undocumented bits for marking filesystem as "dirty" --
incorrectly unmounted.

Would it be possible for MS to release in same way code of exFAT NT
driver? I'm really a bit sceptical that exFAT MS implementation is
really according to standard as I already known that FAT32 is not.

Just to note that I did some investigation in FAT32 level how are
handled volume labels and I found more bugs in current implementations
(mtools, dosfstools, util-linux and even in fastfat.sys). Some
references are on: https://www.spinics.net/lists/kernel/msg2640891.html

Fixes for mtools, dosfstools and util-linux were already applied and fix
for MS's fastfat.sys is pending in opened pull request:
https://github.com/microsoft/Windows-driver-samples/pull/303

Could you please forward my pull request for fastfat.sys fixes to
appropriate people/team in MS?

-- 
Pali Rohár
pali.rohar@gmail.com

  reply index

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-28 16:08 Greg Kroah-Hartman
2019-08-28 17:00 ` Greg Kroah-Hartman
2019-08-29  6:23   ` Christoph Hellwig
2019-08-29  6:39     ` Greg Kroah-Hartman
2019-08-29  9:41       ` Christoph Hellwig
2019-08-29  9:50         ` Greg Kroah-Hartman
2019-08-29 10:37           ` Christoph Hellwig
2019-08-29 11:04             ` Gao Xiang
2019-08-29 11:18               ` Greg Kroah-Hartman
2019-08-29 11:18             ` Greg Kroah-Hartman
2019-08-29 15:11               ` Dan Carpenter
2019-08-29 15:27                 ` Gao Xiang
2019-08-29 15:43                   ` Dan Carpenter
2019-08-29 15:51                     ` Gao Xiang
2019-08-29 16:04                       ` Gao Xiang
2019-08-30  8:34                         ` Dan Carpenter
2019-08-30  8:43                           ` Gao Xiang
2019-08-30 11:26                             ` Dan Carpenter
2019-08-30 12:04                               ` Gao Xiang
2019-08-29 16:44                     ` Gao Xiang
2019-08-29 16:59                       ` Joe Perches
2019-08-29 17:02                         ` Gao Xiang
2019-08-30  2:06                     ` Chao Yu
2019-08-30  6:38                       ` Gao Xiang
2019-08-30 12:00                         ` Checking usage of likeliness annotations Markus Elfring
2019-08-30 11:51                       ` [PATCH] staging: exfat: add exfat filesystem code to staging David Sterba
2019-08-31  3:50                         ` Chao Yu
2019-08-30 15:36               ` Christoph Hellwig
2019-08-30 21:54               ` Dave Chinner
2019-08-31 10:31                 ` Valdis Klētnieks
2019-09-01  0:04                   ` Dave Chinner
2019-08-29  7:01     ` Gao Xiang
2019-08-29  8:24       ` Gao Xiang
2019-08-29  9:51         ` Christoph Hellwig
2019-08-29 12:14 ` Pali Rohár
2019-08-29 12:34   ` Valdis Klētnieks
2019-08-29 12:46     ` Pali Rohár
2019-08-29 14:08 ` Markus Elfring
2019-08-29 15:44 ` Markus Elfring
2019-08-29 20:56 ` Pali Rohár
2019-08-29 23:18   ` Valdis Klētnieks
2019-08-29 23:35     ` Sasha Levin
2019-08-30  7:56       ` Pali Rohár [this message]
2019-08-30  8:03     ` Pali Rohár
2019-08-30 15:40   ` Christoph Hellwig
2019-08-30 15:43     ` Pali Rohár
2019-09-14 13:39 ` [PATCH] staging: exfat: add exfat filesystem code to Park Ju Hyung
2019-09-15 13:54   ` Greg KH
2019-09-15 16:11     ` Ju Hyung Park
     [not found] ` <20190918195920.25210-1-qkrwngud825@gmail.com>
2019-09-18 20:12   ` [PATCH] staging: exfat: rebase to sdFAT v2.2.0 Greg KH
2019-09-18 20:13   ` Greg KH
2019-09-18 20:22     ` Ju Hyung Park
2019-09-18 20:26       ` Greg KH
2019-09-18 20:31         ` Ju Hyung Park
2019-09-18 20:46           ` Valdis Klētnieks
2019-09-18 21:31   ` kbuild test robot
2019-09-18 21:31   ` kbuild test robot
2019-09-18 22:17     ` Ju Hyung Park

Reply instructions:

You may reply publically 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=20190830075647.wvhrx4asnkrfkkwk@pali \
    --to=pali.rohar@gmail.com \
    --cc=alexander.levin@microsoft.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sashal@kernel.org \
    --cc=valdis.kletnieks@vt.edu \
    /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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org linux-kernel@archiver.kernel.org
	public-inbox-index lkml


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox