All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Daeho Jeong <daeho.jeong@samsung.com>
Subject: Re: linux-next: manual merge of the f2fs tree with the ext4 tree
Date: Mon, 16 May 2016 19:55:39 -0400	[thread overview]
Message-ID: <20160516235539.GR7799@thunk.org> (raw)
In-Reply-To: <20160516222241.GA40269@jaegeuk.gateway>

On Mon, May 16, 2016 at 03:22:41PM -0700, Jaegeuk Kim wrote:
> > Sorry, I just ran out of time to try to verify that the patch wouldn't
> > break anything, and given that we're going to need to wait for
> > "fscrypto/f2fs: allow fs-specific key prefix for fs encryption" to go
> > upstream.
> 
> Agreed. IIUC, let me push the fscrypto/f2fs patch to v4.7 first?

Right --- that's in linux-next already, right?  And currently it's a
combined fscrypto/f2fs patch, which is why I suspect letting it go
into v4.7 first makes sense.  I'll make sure the ext4 move to
fs/crypto will be one of the first development patches for 4.8 (modulo
any urgent bug fixes that need to go into 4.7 final first).

> I have no planned patch right now, and of course, it must have no problem for
> you to treat with further patches.
> Also, let me take a look at any missing part again, regarding to your concerns.

I'm sure there may be some missing pieces around using file system
level crypto for the desktop / server use case.  Some of them are in
how we handle removable thumb drives, for example.

There are definitely some missing pieces about how to handle removable
SD cards for Android, as well, including some kernel-side patches that
are currently living in the unstable portion of the ext4 patch queue.
We never got the design, implementation and kernel<->userspace API's
fully baked, so that's not going upstream any time soon, but all of
this means that we will need to figure out what's the best way to
develop, test, and push fs/crypto changes in the long term.  This may
mean a new git tree with shared maintenance, as one way that we could
do things.

       		       	       	       	     - Ted

  reply	other threads:[~2016-05-16 23:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-08 23:36 linux-next: manual merge of the f2fs tree with the ext4 tree Stephen Rothwell
2016-05-09 17:15 ` Jaegeuk Kim
2016-05-16 21:30   ` Theodore Ts'o
2016-05-16 22:22     ` Jaegeuk Kim
2016-05-16 23:55       ` Theodore Ts'o [this message]
2016-09-19  1:26 Stephen Rothwell

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=20160516235539.GR7799@thunk.org \
    --to=tytso@mit.edu \
    --cc=daeho.jeong@samsung.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.