Re: Merging backported fscrypt to 4.4?

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Oct 12, 2017 at 11:59:03AM +0000, Anton Altaparmakov wrote:
> Hi Greg,
> 
> As 4.4 is now going to be "the stable kernel" until 2022 and we have backported fscrypt to 4.4.  Currently we (that is Tuxera) have it as an out of tree proof of concept module and we could maintain it like that but given the kernel is going to be around for another 5 years perhaps it would be useful for everyone to have fscrypt in the stable 4.4 tree itself...  Then ext4/f2fs could support fscrypt based encryption in the 4.4 kernel which is of interest to many device manufacturers (which is why we have done the backport - it was driven by customers)...
> 
> What do you think?  Would you accept a backported fscrypt into the stable 4.4 tree?

The LTS rules are still the same, no matter if I maintain it for a few
months, or a few years/decades.  So how does adding a bunch of new code
for no in-kernel users fit into the existing rules?

If a device manufacture wants the fscrypt feature, great, use a newer
kernel (like 4.9 or better yet, 4.14.)  It's always best to use newer
kernels, right?

> Note, the reason I am asking before sending patches is that we need to make some changes to our current backport if it is going into the kernel as we need to update the struct inode and struct super_block.  (We currently work around this in the out of tree fscrypt module but it would be much cleaner to have it all done in the correct places as it is in the current fscrypt in mainline.)

You should convince your customers to use a more modern kernel :)

thanks,

greg k-h