|Parametrization||run-time mostly||compile-time mostly|
|Linux-based devices (embedded SMB)|
As can be seen from the comparison above CIFSFS and YNQ™ SMB Clients complement each other in terms of the use domains, fine-tuning etc. That is to say that both SMB Clients offer more or less the same features, SMB-wise.
With CIFSFS solution a user just plugs a remote share to the local folder tree and since then he/she can transparently benefit from SMB connectivity through any existing application, being office or a game.
YNQ™, in the contrary, is dedicated to embedded solutions, when SMB connectivity must be granted to a particular code being developed towards a dedicated application, like printer or robot firmware*.
As a part of most Linux editions, CIFSFS is installed together with the operating system and then becomes available system-wide. This solution comes as a kernel module.
YNQ™ comes as a library and must be linked together with the firmware code or application code.
CIFSFS resides in the kernel and, therefore, it benefits from being close to the essential services. The word “latency” is widely used in the context of kernel space advantages. A comparison of the kernel-space solution versus user space solutions in terms of latency may bring us too far above the framework of this article. Just to mention that concentrating as much processing as possible in the kernel space is definitely one (but not the only) method of reducing the latency.
YNQ™ resides in the user space as an integral part of the software/firmware application. In contrary to CIFSFS, YNQ™ benefits from being close to the application. For instance, YNQ™ can directly benefit from user-space solutions like DPDK.
As the CIFSFS SMB Client solution comes together with Linux, it has mainly startup or run-time controls. Since this client must provide a generic solution, this seems to be the only way of providing the entire spectrum of possibilities.
YNQ™ provides a dedicated solution. That’s why the most significant YNQ™ controls are applied in compile-time which grants the best tailoring of the SMB Client to the particular application’s requirements. More delicate controls, those that remain inside the application framework, YNQ™ also leaves for run-time.
As one can mention from the above YNQ™ and CIFSF differs in almost everything: from where they reside to whom they serve. Maybe the only match between them is the SMB protocol itself.
Many, many years ago I was frankly convinced that standards will leverage our world making it less diverse and dull. How wrong was I – new standards have raised up but the diversity is still here, e.g., – around SMB.
* YNQ™ is also available through FUSE which makes it more generic and functionally-wise almost equivalent to CIFSFS. However, performance is not the same. Anyway, FUSE usage of YNQ™ is out of this article’s scope.