linux-kernel - Re: [PATCH] staging: exfat: add exfat filesystem code to

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190917054726.GA2058532@kroah.com>
Date:   Tue, 17 Sep 2019 07:47:26 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Park Ju Hyung <qkrwngud825@...il.com>
Cc:     valdis.kletnieks@...edu, namjae.jeon@...sung.com,
        devel@...verdev.osuosl.org, linkinjeon@...il.com,
        linux-kernel@...r.kernel.org, alexander.levin@...rosoft.com,
        sergey.senozhatsky@...il.com, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] staging: exfat: add exfat filesystem code to

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
> > mergeable, I'd not object if that got merged instead.
> 
> Greg, as Valdis mentioned here, the staging tree driver is just another exFAT fork
> from Samsung.
> What's the point of using a much older driver?

It's the fact that it actually was in a form that could be merged, no
one has done that with the sdfat code :)

> sdFAT is clearly more matured and been put into more recent production softwares.
> And as I wrote in previous email, it does include some real fixes.

What fixes?  That's what I'm asking here.

How do we "know" that this is better than what we currently have today?
We don't, so it's a bit hard to tell someone, "delete the work you did
and replace it with this other random chunk of code, causing you a bunch
more work in the process for no specific reason other than it looks
'newer'." :(

> As Namjae said too, Samsung would be more interested in merging sdFAT to upstream.
> If we diverge, Samsung will have less reasons to contribute their patches to upstream.

Are they going to do this if we do take the sdfat code?  If so, great,
but I need to get someone to agree that this will happen.

> Also, I think it makes much more sense to make Samsung the maintainer of this driver
> (if they're willing to put in the manpower to do so). Asking them would be the first
> step in doing so.

They are more than willing to start contributing and being a
co-maintainer of it, it needs all the help it can get.

But "someone" from samsung, or anywhere else, has to be willing to step
up here and do this work.  Without that happening, I don't see a reason
to change at this point in time.

Rembember, kernel development happens because people do the work, which
Valdis did, and continues to do.  Throwing that away because of the
thought that someone else might do some work in the future is not how we
work.

I recommend looking at what we have in the tree now, and seeing what is
missing compared to "sdfat".  I know a lot of places in the exfat code
that needs to be fixed up, odds are they are the same stuff that needs
to be resolved in sdfat as well.

thanks,

greg k-h