-
-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Any plans for upstream? #68
Comments
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.
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.
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 |
I found this old commit from the original repo: I guess you also need to select |
Thanks for the reply! |
As a last question @eafer , anything in the kconfig above which you feel is absolutely unnecessary |
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 |
I settled with this |
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:
The text was updated successfully, but these errors were encountered: