>>>     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