>>>>     Everything but fs compiles and links both dynamically or 
>>>> statically and both with glibc or musl. This is very satisfactory.

>>>>     With  'make -C fs' , I have a compilation error:

>>>>     however such a file exists in the include tree of gcc.

>>>>     I'm not used to include files without a .h extension. Is it a 
>>>> C++ feature? 

>>     "fskit/common.h" *is* the file which is included, and it is 
>> found. But this file itself includes <iostream>. I found iostream 
>> somewhere in C++ system headers; therefore I would expect the C++ 
>> compiler to find it automatically. I suspect some trick is necessary 
>> to help the C compiler find it also. But, as I wrote, I've no 
>> experience in C++ and mixing C and C++. I tried to include <iostream> 
>> with its whole path, but it just displaces the problem.

>>     I'm compiling against a version of fskit I built in may 2015 and 
>> it might be obsolete. I might try to download the latest version.

>>     Anyway vdev proper doesn't depend on this special filesystem, so 
>> that this is a minor problem and isn't at all a blocker for vdev 
>> deployment. For me the primary problem is the failure to create disk 
>> devices. There might be other problems but the log is very verbose 
>> and I better wait until Jude is available to analyse it.

>>     The compilation is going well and I'm convinced that the problems 
>> are caused by details. It might be that they are related to the way 
>> I've configured or invoked vdevd, or the way I've laid out the files. 
>> Therefore, if you are willing to debianize the package, I think you 
>> could start now.

>>     Vdev in the initramfs is absolutely not critical. Busybox comes 
>> with its own mdev hotplugger, which doesn't depend on dbus or 
>> systemd, and there is no need for the hotplugger to be the same in 
>> the initramfs and the final system. Actually I think it would make 
>> sense to use mdev inside the initramfs, this way initramfs would be 
>> independant of the choice of hotplugger for the final system -- to be 
>> discussed. My efforts with Busybox are rather meant for tiny OSes 
>> based on Busybox and musl.

>>     Cheers.
>>                             Didier