driverdev-devel.linuxdriverproject.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Valentin Vidić" <vvidic@valentin-vidic.from.hr>
Cc: devel@driverdev.osuosl.org,
	Valdis Kletnieks <valdis.kletnieks@vt.edu>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: exfat: add millisecond support
Date: Sun, 8 Sep 2019 17:43:41 +0100	[thread overview]
Message-ID: <20190908164341.GC8362@kroah.com> (raw)
In-Reply-To: <20190908144735.GA7664@valentin-vidic.from.hr>

On Sun, Sep 08, 2019 at 02:47:35PM +0000, Valentin Vidić wrote:
> On Sun, Sep 08, 2019 at 02:03:37PM +0100, Greg Kroah-Hartman wrote:
> > Please run checkpatch on your patches so that we don't have to go and
> > fix up those issues later on.
> 
> Strange, it did not report anything for me:
> 
> total: 0 errors, 0 warnings, 0 checks, 439 lines checked
> 0001-staging-exfat-add-millisecond-support.patch has no obvious style problems and is ready for submission.

See my response to the broken out patch as to where it should have
complained.

> > Also, can you break this up into smaller patches please?  You are doing
> > multiple things all at once.
> 
> Sure, I was just trying to improve the code a bit :)

No problem, it's much appreciated.

> > And, are you sure about the millisecond field for access time stuff?  It
> > was obviously added for some reason (there are lots in the spec that the
> > code does not yet cover, this seems odd being the other way around).
> > Did you test it against any other operating system exfat images to
> > ensure that it really is not being used at all?  If so, which ones?
> 
> Don't really have access to another OS, but here is what exfat-fuse has:
> 
> struct exfat_entry_meta1                        /* file or directory info (part 1) */
> {
>         uint8_t type;                                   /* EXFAT_ENTRY_FILE */
>         uint8_t continuations;
>         le16_t checksum;
>         le16_t attrib;                                  /* combination of EXFAT_ATTRIB_xxx */
>         le16_t __unknown1;
>         le16_t crtime, crdate;                  /* creation date and time */
>         le16_t mtime, mdate;                    /* latest modification date and time */
>         le16_t atime, adate;                    /* latest access date and time */
>         uint8_t crtime_cs;                              /* creation time in cs (centiseconds) */
>         uint8_t mtime_cs;                               /* latest modification time in cs */
>         uint8_t __unknown2[10];
> }
> 
> The spec matches this and defines 3 additional UtcOffset fields that we don't use:

I would only go off of the spec, who knows where exfat-fuse got its
information from :)

> EntryType
> SecondaryCount
> SetChecksum
> FileAttributes
> Reserved1
> CreateTimestamp
> LastModifiedTimestamp
> LastAccessedTimestamp
> Create10msIncrement
> LastModified10msIncrement
> 
> CreateUtcOffset (1 byte)
> LastModifiedUtcOffset (1 byte)
> LastAccessedUtcOffset (1 byte)
> Reserved2 (7 bytes)
> 
> So I'm not sure where access_time_ms came from. In any case it was always set to
> 0 so it should not matter much?

If it really is CreateUtcOffset, we should use that.

For things like messing with fields, testing on another operating system
to ensure we got this right is going to be very essential.  Virtual
machines of osx or windows might be a good way to do that.

thanks,

greg k-h
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

      reply	other threads:[~2019-09-08 16:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-08 12:48 [PATCH] staging: exfat: add millisecond support Valentin Vidic
2019-09-08 13:03 ` Greg Kroah-Hartman
2019-09-08 14:47   ` Valentin Vidić
2019-09-08 16:43     ` Greg Kroah-Hartman [this message]

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=20190908164341.GC8362@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=valdis.kletnieks@vt.edu \
    --cc=vvidic@valentin-vidic.from.hr \
    /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;
as well as URLs for NNTP newsgroup(s).