Re: Goal: guestfsd?
On Mon, 2011-09-05 at 22:58 +0200, Samuel Thibault wrote:
> Svante Signell, le Mon 05 Sep 2011 22:02:13 +0200, a écrit :
> > In order to get libguestfs (having package guestfsd) built
>
> I'm not sure to understand: why do you want guestfsd? That's one more
> package, sure, but except from qcow/vmdk images, we can already do what
> it does.
To have faster IO emulation using virtio under kvm than with IDE, see
http://www.linux-kvm.org/page/Tuning_KVM
> > libsys-virt-perl depends on libvirt-dev while
> > fuse and febootstrap needs support/workarounds for mount.h
>
> As I mentioned in another mail, it'd probably better to make them use
> file_set_translator, since the parameters will have to be fixed anyway,
> there is not much benefit in providing an interface which will fail.
Are you saying the this functionality has to implemented from scratch,
including new system header files?
> > As a test I managed to enable libvirt to build by cheating a little when
> > building dnsmasq-base, installing it and then doing some tweaks to get
> > libvirt built.
>
> It can only be accepted as a bootstrap phase. Packages in the main
> archive have to be buildable without patches and with the main packages.
> That is why debian-ports package should only be seen as a way to
> accelerate package built, but eventually everything has to be accepted
> in main.
Of course! It was just a test to see iv livirt was able to build, and it
was without too much tweaking. On question is:
Defined in linux/sys/param.h
/* Unit of `st_blocks'. */
#define DEV_BSIZE 512
Not defined/supported on Hurd.
> > Other missing definitions for dnsmasq are: sockaddr_dl, LLADDR:
> > sys/if_dl.h and IP_RECVIF: sys/netinet/in.h if BSD network or
> > IP_PKTINFO: bits/in.h if Linux network.
>
> This is not so simple: we can not blindly define them to some random
> value. We need to take care which value to give to avoid hindering any
> future implementation.
I assumed they are not implemented (yet). Where does these values
belong? They don't seem to be defined/implemented by the bpf patches.
Reply to: