Any plans for upstream?

[AdityaGarg8]

Hi

I really appreciate your work. I was wondering whether there are plans for upstreaming this driver? Although as far as I understand, since the code of lzfse is not GPL, I guess it won't.

Anyways, I compile my own kernels for the purpose of running Linux on my Mac, and the read support of your driver is quite useful. I now add your driver in my kernel itself. Although, it compiles well, I wanted to know the exact kconfig of this driver that I should use.

My current config is below:

# SPDX-License-Identifier: GPL-2.0-only
config APFS_FS
	tristate "Apple file system support"
	select CRYPTO
	select CRYPTO_CRC32C
	select LIBCRC32C
	select CRYPTO_XXHASH
	select CRYPTO_SHA256
	select CRYPTO_BLAKE2B
	select BUFFER_HEAD
	select FS_IOMAP
	select LEGACY_DIRECT_IO
	help
	  If you say Y here, you will be able to mount APFS partitions
	  with read-only access. Write access is experimental and will
	  corrupt your container.

[eafer]

I was wondering whether there are plans for upstreaming this driver?

This question has come up before. The situation has not changed that much. At the very least I would need to fix the locking and handle ENOSPC better. But I don't expect upstream to be all that interested.

the code of lzfse is not GPL

It's under the 3-clause bsd license, which is compatible with the gpl. The real problem with the lzfse code is that it triggers an objtool warning, probably because of all the crazy gotos.

I wanted to know the exact kconfig

Frankly I have no idea. I only build out of tree these days, and always for standard distro kernels. I'm sure you at least need to select ZLIB_INFLATE as well.

[eafer]

I found this old commit from the original repo:

linux-apfs/linux-apfs@885a04c

I guess you also need to select NLS.

[AdityaGarg8]

Thanks for the reply!

[AdityaGarg8]

As a last question @eafer , anything in the kconfig above which you feel is absolutely unnecessary

[eafer]

You can leave this open if you prefer, I do need to think about Kconfig eventually. As for your question, I don't think we use any of the crypto hashes you selected right now, only crc32c.

[AdityaGarg8]

You can leave this open if you prefer, I do need to think about Kconfig eventually. As for your question, I don't think we use any of the crypto hashes you selected right now, only crc32c.

Alright, I'll reopened

[AdityaGarg8]

# SPDX-License-Identifier: GPL-2.0-only
config APFS_FS
	tristate "Apple file system support"
	select LIBCRC32C
	select ZLIB_INFLATE
	select NLS
	select BUFFER_HEAD
	select FS_IOMAP
	select LEGACY_DIRECT_IO
	help
	  If you say Y here, you will be able to mount APFS partitions
	  with read-only access. Write access is experimental and will
	  corrupt your container.

I settled with this

[ethancedwards8]

@eafer . I would be more than happy to collaborate with you on upstreaming this. I wouldn't mind handling all of the grunt work/bouncing it off the mailing list if you would help me test/help review it once I have a working setup.

[eafer]

@ethancedwards8 I don't see it happening at this point, the upstream filesystem people are very demanding (which is reasonable because a bad filesystem can do a lot of damage). At the very least I would need to get rid of buffer heads first, and I haven't even looked into that.