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
> 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 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.
>
65 matches
Mail list logo
