On Monday 27 April 2020 11:49:13 Sasha Levin wrote:
> On Tue, Apr 21, 2020 at 11:30:45PM +0200, Pali Rohár wrote:
> > On Thursday 13 February 2020 16:18:47 Sasha Levin wrote:
> > > On Thu, Feb 13, 2020 at 01:06:56AM +0100, Pali Rohár wrote:
> > > > In released exFAT specification is not written
On Tue, Apr 21, 2020 at 11:30:45PM +0200, Pali Rohár wrote:
On Thursday 13 February 2020 16:18:47 Sasha Levin wrote:
On Thu, Feb 13, 2020 at 01:06:56AM +0100, Pali Rohár wrote:
> In released exFAT specification is not written how are Unicode code
> points above U+ represented in exFAT
On Thursday 13 February 2020 16:18:47 Sasha Levin wrote:
> On Thu, Feb 13, 2020 at 01:06:56AM +0100, Pali Rohár wrote:
> > In released exFAT specification is not written how are Unicode code
> > points above U+ represented in exFAT upcase table. Normally in
> > UTF-16 are Unicode code points
> Idea is simple. Expects that we have a clean filesystem in correct
> state. We load primary/active/main FAT table (just call it FAT1) and all
> changes to filesystem would be done via second non-active FAT table
> (FAT2). At unmount or sync or flush buffer times, FAT2 would be copied
> back to
On Thu, 13 Feb 2020 16:18:47 -0500, Sasha Levin said:
> >> I was hoping that it would be possible to easily use secondary FAT table
> >> (from TexFAT extension) for redundancy without need to implement full
> >> TexFAT, which could be also backward compatible with systems which do
> >> not
On Friday 14 February 2020 17:16:18 Valdis Klētnieks wrote:
> On Thu, 13 Feb 2020 16:18:47 -0500, Sasha Levin said:
>
> > >> I was hoping that it would be possible to easily use secondary FAT table
> > >> (from TexFAT extension) for redundancy without need to implement full
> > >> TexFAT, which
On Thu, Feb 13, 2020 at 01:06:56AM +0100, Pali Rohár wrote:
Hello!
On Thursday 17 October 2019 09:50:08 Pali Rohár wrote:
On Wednesday 16 October 2019 16:33:17 Sasha Levin wrote:
> On Wed, Oct 16, 2019 at 06:03:49PM +0200, Pali Rohár wrote:
> > On Wednesday 16 October 2019 10:31:13 Sasha Levin
Hello!
On Thursday 17 October 2019 09:50:08 Pali Rohár wrote:
> On Wednesday 16 October 2019 16:33:17 Sasha Levin wrote:
> > On Wed, Oct 16, 2019 at 06:03:49PM +0200, Pali Rohár wrote:
> > > On Wednesday 16 October 2019 10:31:13 Sasha Levin wrote:
> > > > On Wed, Oct 16, 2019 at 04:03:53PM +0200,
On Wednesday 28 August 2019 18:08:17 Greg Kroah-Hartman wrote:
> The full specification of the filesystem can be found at:
> https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification
FYI, it looks like that this released specification is just copy+paste
from exFAT patent
On Wednesday 16 October 2019 17:53:43 Valdis Klētnieks wrote:
> and may cause problems if Linux says "currently using FAT 2", and the
> disk is next used on a Windows 10 box that only looks at FAT 1
You should use same algorithm which is used for FAT32. Primary FAT is
first. And all
On Wednesday 16 October 2019 16:33:17 Sasha Levin wrote:
> On Wed, Oct 16, 2019 at 06:03:49PM +0200, Pali Rohár wrote:
> > On Wednesday 16 October 2019 10:31:13 Sasha Levin wrote:
> > > On Wed, Oct 16, 2019 at 04:03:53PM +0200, Pali Rohár wrote:
> > > > On Friday 30 August 2019 09:56:47 Pali Rohár
On Wed, 16 Oct 2019 16:33:17 -0400, Sasha Levin said:
> It looks like the reason this wasn't made public along with the exFAT
> spec is that TexFAT is pretty much dead - it's old, there are no users
> we are aware of, and digging it out of it's grave to make it public is
> actually quite the
On Wed, Oct 16, 2019 at 06:03:49PM +0200, Pali Rohár wrote:
On Wednesday 16 October 2019 10:31:13 Sasha Levin wrote:
On Wed, Oct 16, 2019 at 04:03:53PM +0200, Pali Rohár wrote:
> On Friday 30 August 2019 09:56:47 Pali Rohár wrote:
> > On Thursday 29 August 2019 19:35:06 Sasha Levin wrote:
> > >
On Wed, Oct 16, 2019 at 06:32:31PM +0200, Pali Rohár wrote:
> On Wednesday 16 October 2019 09:22:11 Greg Kroah-Hartman wrote:
> > On Wed, Oct 16, 2019 at 06:03:49PM +0200, Pali Rohár wrote:
> > > > Can I assume you will be implementing TexFAT support once the spec is
> > > > available?
> > >
> >
On Wednesday 16 October 2019 09:22:11 Greg Kroah-Hartman wrote:
> On Wed, Oct 16, 2019 at 06:03:49PM +0200, Pali Rohár wrote:
> > > Can I assume you will be implementing TexFAT support once the spec is
> > > available?
> >
> > I cannot promise that I would implement something which I do not know
On Wed, Oct 16, 2019 at 06:03:49PM +0200, Pali Rohár wrote:
> > Can I assume you will be implementing TexFAT support once the spec is
> > available?
>
> I cannot promise that I would implement something which I do not know
> how is working... It depends on how complicated TexFAT is and also how
>
On Wed, Oct 16, 2019 at 06:03:49PM +0200, Pali Rohár wrote:
On Wednesday 16 October 2019 10:31:13 Sasha Levin wrote:
On Wed, Oct 16, 2019 at 04:03:53PM +0200, Pali Rohár wrote:
> On Friday 30 August 2019 09:56:47 Pali Rohár wrote:
> > On Thursday 29 August 2019 19:35:06 Sasha Levin wrote:
> > >
On Wed, 16 Oct 2019 10:31:13 -0400, Sasha Levin said:
> On Wed, Oct 16, 2019 at 04:03:53PM +0200, Pali Roh�r wrote:
> >Now one month passed, so do you have some information when missing parts
> >of documentation like TexFAT would be released to public?
>
> Sure, I'll see if I can get an approval
On Wednesday 16 October 2019 10:31:13 Sasha Levin wrote:
> On Wed, Oct 16, 2019 at 04:03:53PM +0200, Pali Rohár wrote:
> > On Friday 30 August 2019 09:56:47 Pali Rohár wrote:
> > > On Thursday 29 August 2019 19:35:06 Sasha Levin wrote:
> > > > With regards to missing specs/docs/whatever - our main
On Wed, Oct 16, 2019 at 04:03:53PM +0200, Pali Rohár wrote:
On Friday 30 August 2019 09:56:47 Pali Rohár wrote:
On Thursday 29 August 2019 19:35:06 Sasha Levin wrote:
> With regards to missing specs/docs/whatever - our main concern with this
> release was that we want full interoperability,
On Friday 30 August 2019 09:56:47 Pali Rohár wrote:
> On Thursday 29 August 2019 19:35:06 Sasha Levin wrote:
> > 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
On Mon, Sep 30, 2019 at 01:25:13PM +0900, Namjae Jeon wrote:
>
> > [..]
> > > Put it in drivers/staging/sdfat/.
> > >
> > > But really we want someone from Samsung to say that they will treat
> > > the staging version as upstream. It doesn't work when people apply
> > > fixes to their version
> [..]
> > Put it in drivers/staging/sdfat/.
> >
> > But really we want someone from Samsung to say that they will treat
> > the staging version as upstream. It doesn't work when people apply
> > fixes to their version and a year later back port the fixes into
> > staging. The staging tree is
[..]
> Put it in drivers/staging/sdfat/.
>
> But really we want someone from Samsung to say that they will treat
> the staging version as upstream. It doesn't work when people apply
> fixes to their version and a year later back port the fixes into
> staging. The staging tree is going to have
On Wed, Sep 18, 2019 at 07:46:25PM +0900, Ju Hyung Park wrote:
> On Wed, Sep 18, 2019 at 7:09 PM Dan Carpenter
> wrote:
> > Use Kconfig.
>
> Not just that.
> There are a lot of non-static functions that's not marked ex/sdfat-specific.
> (which we would have to clean it up eventually)
Then
On Wed, Sep 18, 2019 at 7:09 PM Dan Carpenter wrote:
> Use Kconfig.
Not just that.
There are a lot of non-static functions that's not marked ex/sdfat-specific.
(which we would have to clean it up eventually)
Even with sdFAT base, there are some non-static functions named as exfat.
Figuring out
On Wed, Sep 18, 2019 at 06:53:49PM +0900, Ju Hyung Park wrote:
> Hi Dan,
>
> On Wed, Sep 18, 2019 at 6:27 PM Dan Carpenter
> wrote:
> > Put it in drivers/staging/sdfat/.
>
> It'll conflict with the current exfat staging drivers.
Use Kconfig.
> And moreover, I don't think it makes sense to
Hi Dan,
On Wed, Sep 18, 2019 at 6:27 PM Dan Carpenter wrote:
> Put it in drivers/staging/sdfat/.
It'll conflict with the current exfat staging drivers.
And moreover, I don't think it makes sense to use sdfat naming in mainline.
Samsung uses it since it handles all fat filesystems.
>From what I
On Wed, Sep 18, 2019 at 06:01:09PM +0900, Ju Hyung Park wrote:
> On Wed, Sep 18, 2019 at 5:33 PM Greg KH wrote:
> > He did? I do not see a patch anywhere, what is the message-id of it?
>
> I'm just repeating myself at this point, but again, I'm more than
> willing to work on a patch.
> I just
On Wed, Sep 18, 2019 at 5:33 PM Greg KH wrote:
> He did? I do not see a patch anywhere, what is the message-id of it?
I'm just repeating myself at this point, but again, I'm more than
willing to work on a patch.
I just want to make it clear on how should I.
> He took the "best known at the
On (09/18/19 10:26), 'Greg KH' wrote:
> On Wed, Sep 18, 2019 at 03:33:04PM +0900, Sergey Senozhatsky wrote:
> > On (09/18/19 08:16), 'Greg KH' wrote:
> > [..]
> > > > Note, that Samsung is still improving sdfat driver. For instance,
> > > > what will be realeased soon is sdfat v2.3.0, which will
On Wed, Sep 18, 2019 at 03:33:04PM +0900, Sergey Senozhatsky wrote:
> On (09/18/19 08:16), 'Greg KH' wrote:
> [..]
> > > Note, that Samsung is still improving sdfat driver. For instance,
> > > what will be realeased soon is sdfat v2.3.0, which will include support
> > > for "UtcOffset" of "File
On (09/18/19 08:16), 'Greg KH' wrote:
[..]
> > Note, that Samsung is still improving sdfat driver. For instance,
> > what will be realeased soon is sdfat v2.3.0, which will include support
> > for "UtcOffset" of "File Directory Entry", in order to satisfy
> > exFAT specification 7.4.
>
[..]
> If
A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
A: No.
Q: Should I
g.com; Valdis Kletnieks
> Cc: de...@driverdev.osuosl.org; linkinj...@gmail.com; linux-
> ker...@vger.kernel.org; alexander.le...@microsoft.com;
> sergey.senozhat...@gmail.com; linux-fsde...@vger.kernel.org
> Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to
>
> On Tue, Sep 17,
On Tue, Sep 17, 2019 at 2:47 PM Greg KH wrote:
> It's the fact that it actually was in a form that could be merged, no
> one has done that with the sdfat code :)
Well, I'm more than happy to help if you guys are happy with merging
the new base.
> What fixes? That's what I'm asking here.
I
On Tue, Sep 17, 2019 at 02:31:34PM +0900, Park Ju Hyung wrote:
> On Tue, 17 Sep 2019 00:19:36 -0400, "Valdis Klētnieks" said:
> > I'm working off a somewhat cleaned up copy of Samsung's original driver,
> > because that's what I had knowledge of. If the sdfat driver is closer to
> > being
> >
On Tue, 17 Sep 2019 00:19:36 -0400, "Valdis Klētnieks" said:
> I'm working off a somewhat cleaned up copy of Samsung's original driver,
> because that's what I had knowledge of. If the sdfat driver is closer to
> being
> mergeable, I'd not object if that got merged instead.
Greg, as Valdis
.
Thanks,
Gao Xiang
>
> Thanks!
>
> > -- Forwarded message -
> > : Ju Hyung Park
> > Date: 2019?? 9?? 16?? (??) ???? 3:49
> > Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to
> > To: Greg KH
> > Cc:
On Tue, Sep 17, 2019 at 12:02:01PM +0900, Namjae Jeon wrote:
> We are excited to see this happening and would like to state that we
> appreciate
> time and
> effort which people put into upstreaming exfat. Thank you!
>
> However, if possible, can we step back a little bit and re-consider it? We
On Tue, 17 Sep 2019 12:02:01 +0900, "Namjae Jeon" said:
> We are excited to see this happening and would like to state that we
> appreciate time and
> effort which people put into upstreaming exfat. Thank you!
The hard part - getting Microsoft to OK merging an exfat driver - is done.
All we
products - sdfat - as
this can
be mutually benefitial from various points of view.
Thanks!
> -- Forwarded message -
> 보낸사람: Ju Hyung Park
> Date: 2019년 9월 16일 (월) 오전 3:49
> Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to
> To: Greg KH
Hi Greg,
On Sun, Sep 15, 2019 at 10:54 PM Greg KH wrote:
> Note, this just showed up publically on August 12, where were you with
> all of this new code before then? :)
My sdFAT port, exfat-nofuse and the one on the staging tree, were all
made by Samsung.
And unless you guys had a chance to
On Sat, Sep 14, 2019 at 10:39:51PM +0900, Park Ju Hyung wrote:
> Hi.
>
> I just noticed that this exfat-staging drivers are based on the old
> Samsung's 1.x exFAT drivers.
>
> I've been working to get the newer Samsung's driver(now named "sdFAT")
> to fit better for general Linux users, and I
Hi.
I just noticed that this exfat-staging drivers are based on the old
Samsung's 1.x exFAT drivers.
I've been working to get the newer Samsung's driver(now named "sdFAT")
to fit better for general Linux users, and I believe it can provide a
better base for the community to work on(and
On Sat, Aug 31, 2019 at 06:31:45AM -0400, Valdis Klētnieks wrote:
> On Sat, 31 Aug 2019 07:54:10 +1000, Dave Chinner said:
>
> > The correct place for new filesystem review is where all the
> > experienced filesystem developers hang out - that's linux-fsdevel,
> > not the driver staging tree.
>
On Sat, 31 Aug 2019 07:54:10 +1000, Dave Chinner said:
> The correct place for new filesystem review is where all the
> experienced filesystem developers hang out - that's linux-fsdevel,
> not the driver staging tree.
So far everything's been cc'ed to linux-fsdevel, which has been spending
more
On 2019/8/30 19:51, David Sterba wrote:
> On Fri, Aug 30, 2019 at 10:06:25AM +0800, Chao Yu wrote:
>> On 2019/8/29 23:43, Dan Carpenter wrote:
p.s. There are 2947 (un)likely places in fs/ directory.
>>>
>>> I was complaining about you adding new pointless ones, not existing
>>> ones. The
On Thu, Aug 29, 2019 at 01:18:10PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Aug 29, 2019 at 03:37:49AM -0700, Christoph Hellwig wrote:
> > On Thu, Aug 29, 2019 at 11:50:19AM +0200, Greg Kroah-Hartman wrote:
> > > I know the code is horrible, but I will gladly take horrible code into
> > >
On Friday 30 August 2019 08:40:06 Christoph Hellwig wrote:
> On Thu, Aug 29, 2019 at 10:56:31PM +0200, Pali Rohár wrote:
> > 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
On Thu, Aug 29, 2019 at 10:56:31PM +0200, Pali Rohár wrote:
> 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
On Thu, Aug 29, 2019 at 01:18:10PM +0200, Greg Kroah-Hartman wrote:
> Hey, that's not nice, erofs isn't a POS. It could always use more
> review, which the developers asked for numerous times.
>
> There's nothing different from a filesystem compared to a driver. If
> its stand-alone, and
Hi Dan,
On Fri, Aug 30, 2019 at 02:26:12PM +0300, Dan Carpenter wrote:
> On Fri, Aug 30, 2019 at 04:43:33PM +0800, Gao Xiang wrote:
> > Hi Dan,
> >
> > On Fri, Aug 30, 2019 at 11:34:45AM +0300, Dan Carpenter wrote:
> > > On Fri, Aug 30, 2019 at 12:04:41AM +0800, Gao Xiang wrote:
> > > > Anyway,
On Fri, Aug 30, 2019 at 10:06:25AM +0800, Chao Yu wrote:
> On 2019/8/29 23:43, Dan Carpenter wrote:
> >> p.s. There are 2947 (un)likely places in fs/ directory.
> >
> > I was complaining about you adding new pointless ones, not existing
> > ones. The likely/unlikely annotations are supposed to
On Fri, Aug 30, 2019 at 04:43:33PM +0800, Gao Xiang wrote:
> Hi Dan,
>
> On Fri, Aug 30, 2019 at 11:34:45AM +0300, Dan Carpenter wrote:
> > On Fri, Aug 30, 2019 at 12:04:41AM +0800, Gao Xiang wrote:
> > > Anyway, I'm fine to delete them all if you like, but I think majority of
> > > these
> > >
Hi Dan,
On Fri, Aug 30, 2019 at 11:34:45AM +0300, Dan Carpenter wrote:
> On Fri, Aug 30, 2019 at 12:04:41AM +0800, Gao Xiang wrote:
> > Anyway, I'm fine to delete them all if you like, but I think majority of
> > these
> > are meaningful.
> >
> > data.c- /* page is already locked */
On Fri, Aug 30, 2019 at 12:04:41AM +0800, Gao Xiang wrote:
> Anyway, I'm fine to delete them all if you like, but I think majority of these
> are meaningful.
>
> data.c- /* page is already locked */
> data.c- DBG_BUGON(PageUptodate(page));
> data.c-
> data.c:
On Thursday 29 August 2019 19:18:16 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
>
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
> > >
Hi Dan,
On Fri, Aug 30, 2019 at 10:06:25AM +0800, Chao Yu wrote:
> On 2019/8/29 23:43, Dan Carpenter wrote:
> >> p.s. There are 2947 (un)likely places in fs/ directory.
> >
> > I was complaining about you adding new pointless ones, not existing
> > ones. The likely/unlikely annotations are
On 2019/8/29 23:43, Dan Carpenter wrote:
>> p.s. There are 2947 (un)likely places in fs/ directory.
>
> I was complaining about you adding new pointless ones, not existing
> ones. The likely/unlikely annotations are supposed to be functional and
> not decorative. I explained this very clearly.
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
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
>
On Wednesday 28 August 2019 18:08:17 Greg Kroah-Hartman wrote:
> From: Valdis Klētnieks
>
> The exfat code needs a lot of work to get it into "real" shape for
> the fs/ part of the kernel, so put it into drivers/staging/ for now so
> that it can be worked on by everyone in the community.
>
>
On Fri, 2019-08-30 at 00:44 +0800, Gao Xiang wrote:
> Hi Dan,
>
> On Thu, Aug 29, 2019 at 11:43:46PM +0800, Dan Carpenter wrote:
> > > p.s. There are 2947 (un)likely places in fs/ directory.
> >
> > I was complaining about you adding new pointless ones, not existing
> > ones. The
Hi Joe,
On Thu, Aug 29, 2019 at 09:59:21AM -0700, Joe Perches wrote:
> On Fri, 2019-08-30 at 00:44 +0800, Gao Xiang wrote:
> > Hi Dan,
> >
> > On Thu, Aug 29, 2019 at 11:43:46PM +0800, Dan Carpenter wrote:
> > > > p.s. There are 2947 (un)likely places in fs/ directory.
> > >
> > > I was
Hi Dan,
On Thu, Aug 29, 2019 at 11:43:46PM +0800, Dan Carpenter wrote:
> > p.s. There are 2947 (un)likely places in fs/ directory.
>
> I was complaining about you adding new pointless ones, not existing
> ones. The likely/unlikely annotations are supposed to be functional and
> not decorative.
Hi Dan,
On Thu, Aug 29, 2019 at 11:51:27PM +0800, Gao Xiang wrote:
> Hi Dan,
>
> On Thu, Aug 29, 2019 at 06:43:46PM +0300, Dan Carpenter wrote:
> > > p.s. There are 2947 (un)likely places in fs/ directory.
> >
> > I was complaining about you adding new pointless ones, not existing
> > ones.
Hi Dan,
On Thu, Aug 29, 2019 at 06:43:46PM +0300, Dan Carpenter wrote:
> > p.s. There are 2947 (un)likely places in fs/ directory.
>
> I was complaining about you adding new pointless ones, not existing
> ones. The likely/unlikely annotations are supposed to be functional and
> not decorative.
> +++ b/drivers/staging/exfat/exfat_core.c
> @@ -0,0 +1,3704 @@
…
> +static s32 __load_upcase_table(struct super_block *sb, sector_t sector,
> +u32 num_sectors, u32 utbl_checksum)
> +{
…
> +error:
An other label would be nicer, wouldn't it?
> + if (tmp_bh)
> +
> p.s. There are 2947 (un)likely places in fs/ directory.
I was complaining about you adding new pointless ones, not existing
ones. The likely/unlikely annotations are supposed to be functional and
not decorative. I explained this very clearly.
Probably most of the annotations in fs/ are wrong
Hi Dan,
On Thu, Aug 29, 2019 at 06:11:44PM +0300, Dan Carpenter wrote:
> On Thu, Aug 29, 2019 at 01:18:10PM +0200, Greg Kroah-Hartman wrote:
> > It could always use more review, which the developers asked for
> > numerous times.
>
> I stopped commenting on erofs style because all the
On Thu, Aug 29, 2019 at 01:18:10PM +0200, Greg Kroah-Hartman wrote:
> It could always use more review, which the developers asked for
> numerous times.
I stopped commenting on erofs style because all the likely/unlikely()
nonsense is a pet peeve.
regards,
dan carpenter
> +++ b/drivers/staging/exfat/exfat.h
> @@ -0,0 +1,973 @@
…
> +/* file types */
> +#define TYPE_UNUSED 0x
> +#define TYPE_DELETED 0x0001
…
> +/* time modes */
> +#define TM_CREATE0
> +#define TM_MODIFY1
Will it be helpful to work with enumerations at
On Thursday 29 August 2019 08:34:04 Valdis Klētnieks wrote:
> On Thu, 29 Aug 2019 14:14:35 +0200, Pali Roh?r said:
> > On Wednesday 28 August 2019 18:08:17 Greg Kroah-Hartman wrote:
> > > The full specification of the filesystem can be found at:
> > >
> > >
On Thu, 29 Aug 2019 14:14:35 +0200, Pali Roh�r said:
> On Wednesday 28 August 2019 18:08:17 Greg Kroah-Hartman wrote:
> > The full specification of the filesystem can be found at:
> > https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification
>
> This is not truth. This
On Thu, Aug 29, 2019 at 07:04:43PM +0800, Gao Xiang wrote:
> On Thu, Aug 29, 2019 at 03:37:49AM -0700, Christoph Hellwig wrote:
> > On Thu, Aug 29, 2019 at 11:50:19AM +0200, Greg Kroah-Hartman wrote:
> > > I did try just that, a few years ago, and gave up on it. I don't think
> > > it can be
On Thu, Aug 29, 2019 at 03:37:49AM -0700, Christoph Hellwig wrote:
> On Thu, Aug 29, 2019 at 11:50:19AM +0200, Greg Kroah-Hartman wrote:
> > I did try just that, a few years ago, and gave up on it. I don't think
> > it can be added to the existing vfat code base but I am willing to be
> > proven
On Thu, Aug 29, 2019 at 03:37:49AM -0700, Christoph Hellwig wrote:
> On Thu, Aug 29, 2019 at 11:50:19AM +0200, Greg Kroah-Hartman wrote:
> > I did try just that, a few years ago, and gave up on it. I don't think
> > it can be added to the existing vfat code base but I am willing to be
> > proven
On Thu, Aug 29, 2019 at 11:50:19AM +0200, Greg Kroah-Hartman wrote:
> I did try just that, a few years ago, and gave up on it. I don't think
> it can be added to the existing vfat code base but I am willing to be
> proven wrong.
And what exactly was the problem?
>
> Now that we have the specs,
On Thu, Aug 29, 2019 at 04:24:09PM +0800, Gao Xiang wrote:
> It seems I misunderstood your idea, sorry about that... EROFS
> properly uses vfs interfaces (e.g. we also considered RCU symlink
> lookup path at the very beginning of our design as Al said [1],
> except for mount interface as Al
On Thu, Aug 29, 2019 at 02:41:36AM -0700, Christoph Hellwig wrote:
> On Thu, Aug 29, 2019 at 08:39:55AM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Aug 28, 2019 at 11:23:40PM -0700, Christoph Hellwig wrote:
> > > Can we please just review the damn thing and get it into the proper
> > > tree?
On Thu, Aug 29, 2019 at 08:39:55AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 28, 2019 at 11:23:40PM -0700, Christoph Hellwig wrote:
> > Can we please just review the damn thing and get it into the proper
> > tree? That whole concept of staging file systems just has been one
> > fricking
Hi Christoph,
On Thu, Aug 29, 2019 at 03:01:49PM +0800, Gao Xiang wrote:
> Hi Christoph,
>
> On Wed, Aug 28, 2019 at 11:23:40PM -0700, Christoph Hellwig wrote:
> > Can we please just review the damn thing and get it into the proper
> > tree? That whole concept of staging file systems just has
Hi Christoph,
On Wed, Aug 28, 2019 at 11:23:40PM -0700, Christoph Hellwig wrote:
> Can we please just review the damn thing and get it into the proper
> tree? That whole concept of staging file systems just has been one
> fricking disaster, including Greg just moving not fully reviewed ones
>
On Wed, Aug 28, 2019 at 11:23:40PM -0700, Christoph Hellwig wrote:
> Can we please just review the damn thing and get it into the proper
> tree? That whole concept of staging file systems just has been one
> fricking disaster, including Greg just moving not fully reviewed ones
> over like erofs
Can we please just review the damn thing and get it into the proper
tree? That whole concept of staging file systems just has been one
fricking disaster, including Greg just moving not fully reviewed ones
over like erofs just because he feels like it. I'm getting sick and
tired of this scheme.
On Wed, Aug 28, 2019 at 06:08:17PM +0200, Greg Kroah-Hartman wrote:
> From: Valdis Klētnieks
>
> The exfat code needs a lot of work to get it into "real" shape for
> the fs/ part of the kernel, so put it into drivers/staging/ for now so
> that it can be worked on by everyone in the community.
>
88 matches
Mail list logo
