@prakashsurya Thanks for splitting out the change regarding the file system part, that makes things clearer.
Honestly though, no, I still feel like this is the wrong approach in terms of leveraging the fake kernel library. But the fake kernel and libzpool are similar to me in so far as their goal is to emulate the kernel. This is a user land program which really shouldn't need any of these and while portability isn't my first concern, starts making things pretty odd for those porting this. Honestly, if we take a step back at the original version, the only thing I was unhappy with was saying that we had a general purpose taskq user library because you weren't giving control to applications about how to handle memory allocation by using the umem fatal stuff. If we had scoped that to be private just for zfs or private in so far as just the fake kernel and the zfs user land commands using it, it probably would be a better approach. I'm sorry that I haven't been as active in the other parts. When I saw the fake kernel bits going on, I hadn't realized it was going on for use here. I'm not sure if it makes sense. I see that there's now been Andy's changes and breaking it up further. But honestly, this still feels like a lot of complexity that we're introducing into the headers and builds and complications. I'll take a look at this current version and try to evaluate it. I'll try and hold my breath about the fake kernel bits. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/536#issuecomment-364673929 ------------------------------------------ openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T22334a01fda83bfd-M1d32a62dcfc3381456eefbc4 Powered by Topicbox: https://topicbox.com
