@prakashsurya I do think libzfs in general being a consumer of a fake kernel library is the wrong thing. I mean, wouldn't you say the same thing if it was linked against libzpool? It feels like we're going to all these contortions to emulate a kernel environment which we don't do for other code and things that are shared between user land and the kernel. Even things like ctf or avl trees have code in common that builds in either environment and glue in the user land and the kernel.
Again, I realize I'm probably to blame for how we got here since you all first proposed a generic taskq API that looked like the kernels, but basically made it impossible for the non-libzfs panic on out of memory case. It would probably have been better to have that and have the fake kernel bits rely on that same thing, then the other way around. But everyone's already done the work in the other direction, which is unfortunate, but reality. I'm not sure I can sign off as being a reviewer on this. I can understand that folks don't want to change, but then I would request that you make it very clear to the RTI advocates that there are actual concerns with this from an architectural perspective. I would bet that changes to the fake kernel code and header games are going to impact this in the future. -- 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-366295158 ------------------------------------------ openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T22334a01fda83bfd-Mf29bf8801d27f805c6924e09 Powered by Topicbox: https://topicbox.com
