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 how
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 upcase
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 ab
On Tuesday 10 March 2020 11:54:21 Greg Kroah-Hartman wrote:
> Now that there is a "real" solution for exfat in the vfs tree queued up
> to be merged in 5.7-rc1 the "old" exfat code in staging can be removed.
>
> Many thanks to Valdis for doing the work to get this into the tree in
> the first plac
On Tue, 10 Mar 2020 11:54:21 +0100, Greg Kroah-Hartman said:
> Now that there is a "real" solution for exfat in the vfs tree queued up
> to be merged in 5.7-rc1 the "old" exfat code in staging can be removed.
>
> Many thanks to Valdis for doing the work to get this into the tree in
> the first plac
> 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 t
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 impleme
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 co
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 https://
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 operations
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 heada
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 t
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, whic
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 modif
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 and
> [..]
> > 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 g
[..]
> 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 to
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 clean
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 use
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 wa
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 time
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 in
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 Dir
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 Sa
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 includ
amsung.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, 20
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 gave
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
> > mer
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 menti
gnore me...
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
>
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 need
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 tal
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 b
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 hopeful
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 t
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 like
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
> > > staging
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 implem
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 touches
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, I
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 be
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
> > > a
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
> > > ma
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 suppo
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 fs/f
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
> n
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.
>
> The
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 likely/unlikely
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 complain
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. The
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 likely/unlik
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 su
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:
> > >
> > > https://docs.microsoft.com/en-us/windo
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 specificati
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 specification is not "full". There are missing
important details, like ho
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 added
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 w
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 w
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 mention
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? That
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 disas
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 be
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
> ove
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 ju
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.
>
ux-ker...@vger.kernel.org; de...@driverdev.osuosl.org; Sasha Levin
>
> Subject: Re: exfat filesystem
>
> On Tue, 09 Jul 2019 16:39:31 -, KY Srinivasan said:
>
> > Let me dig up the details here.
>
> In case this helps clarify the chain of events, the code in quest
bject: exfat filesystem
On Tue, Jul 09, 2019 at 11:30:39AM -0400, Theodore Ts'o wrote:
> On Tue, Jul 09, 2019 at 04:21:36AM -0700, Matthew Wilcox wrote:
> > How does
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > w.zdnet.com%2Farticle%2Fmi
On Tue, 2019-07-09 at 12:37 -0400, Sasha Levin wrote:
> On Tue, Jul 09, 2019 at 08:48:34AM -0700, Matthew Wilcox wrote:
> > On Tue, Jul 09, 2019 at 11:30:39AM -0400, Theodore Ts'o wrote:
> > > On Tue, Jul 09, 2019 at 04:21:36AM -0700, Matthew Wilcox wrote:
> > > > How does
> > > > https://www.zdnet
past on Linux
products related to the exfat filesystem. While we at Conservancy were
successful in getting the code that implements exfat for Linux released under
GPL (by Samsung), that code has not been upstreamed into Linux. So, Microsoft
has not included any patents they might hold on exfat into th
On Tue, Jul 09, 2019 at 08:48:34AM -0700, Matthew Wilcox wrote:
>
> Interesting analysis. It seems to me that the correct forms would be
> observed if someone suitably senior at Microsoft accepted the work from
> Valdis and submitted it with their sign-off. KY, how about it?
It might be that th
On Tue, Jul 09, 2019 at 08:48:34AM -0700, Matthew Wilcox wrote:
On Tue, Jul 09, 2019 at 11:30:39AM -0400, Theodore Ts'o wrote:
On Tue, Jul 09, 2019 at 04:21:36AM -0700, Matthew Wilcox wrote:
> How does
>
https://www.zdnet.com/article/microsoft-open-sources-its-entire-patent-portfolio/
> change
On Tue, 09 Jul 2019 08:48:34 -0700, Matthew Wilcox said:
> Interesting analysis. It seems to me that the correct forms would be
> observed if someone suitably senior at Microsoft accepted the work from
> Valdis and submitted it with their sign-off. KY, how about it?
I'd be totally OK with that.
On Tue, 2019-07-09 at 08:48 -0700, Matthew Wilcox wrote:
> On Tue, Jul 09, 2019 at 11:30:39AM -0400, Theodore Ts'o wrote:
> > On Tue, Jul 09, 2019 at 04:21:36AM -0700, Matthew Wilcox wrote:
> > > How does
> > > https://www.zdnet.com/article/microsoft-open-sources-its-entire-p
> > > atent-portfolio/
On Tue, Jul 09, 2019 at 11:30:39AM -0400, Theodore Ts'o wrote:
> On Tue, Jul 09, 2019 at 04:21:36AM -0700, Matthew Wilcox wrote:
> > How does
> > https://www.zdnet.com/article/microsoft-open-sources-its-entire-patent-portfolio/
> > change your personal opinion?
>
> According to SFC's legal analysi
100 matches
Mail list logo
