On 19/02/19 14:15, Matthew Wilcox wrote: > On Tue, Feb 19, 2019 at 01:51:19PM +0200, Boaz harrosh wrote: >> Please see first patch for License of this project >> >> Current status: There are a couple of trivial open-source filesystem >> implementations and a full blown proprietary implementation from Netapp. > > I regard this patchset as being an attempt to avoid your obligations > under the GPL. As such, I will not be reviewing this code and I oppose > its inclusion. > Dearest Matthew One day We'll sit on a bear and you explain to me. I do trust your opinion, but I do not understand. Specifically the above "full blown proprietary implementation from Netapp" does not break the GPL at all. Parts of it are written in languages alien to the Kernel and parts using user-mode libs and code IP that are not able to live in the Kernel. At the beginning we had code to inject the FS into the application of choice vi ld.so and only selected apps like a DB would have a view of the filesystem. But you can imagine how this is a nightmare for IT. Being POSIX under the Kernel is just so much less inventing the wheel say: backup, disaster-recovery, cloud .... Now actually if you look at the code submitted you will see that we are using very very little out of the Kernel. Actually for comparison FUSE is using the Kernel much heavier. Utilizing page-cache, Kernel re-claimers. Smart write-back the lot. In ZUFS we take the upper most interfaces and send it down stream as is. Where ever there is depth of stack we take the top most level and push that to server as is completely synchronous to the app threads. The only real novelty in this project is something completely new to this submission, it is the new RPC we invented here that utilizes per-cpu Technics to show a kind of performance never seen before between two processes. You are a Kernel contributor, you have IP in the Kernel. Your opinion is very important to me and to Netapp. Please point me to these areas that you feel I have stepped on your IP, and have not respected the GPL? And I would want very much to fix it. Or maybe my sin is that I am to successful? Is the GPL guarded by speed? I mean say FUSE it is already doing all these sins. And or other subsystems that bridge Kernel functionality to user-mode. There are other user-mode "drivers" all over the place. But they are all so slooooooow. So a serious FS or server needs to sit in Kernel. With zufs we can now delegate to user-mode. The kernel becomes a micro-kernel, very-fast-bridge, and moves out of the way. Creating space for serious servers to sit in userland. To summarize. I take your statement very seriously. Please state what service of the GPLed Kernel am I exposing and circumventing and I will want to fix it ASAP. I thought, and my philosophy was to take the POSIX interfaces as high as possible and shove them to userland. In an RPC manner that I invented that is very fast. If there are such areas that I am not doing so. Please show me? Best regards Boaz
