[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Goal: guestfsd?



Svante Signell, le Mon 05 Sep 2011 23:42:02 +0200, a écrit :
> 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

I don't see the relation between guestfsd and virtio. guestfsd is only a
userland library images, which does not talk with the virtio layer.

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

No, file_set_translator already exists, we just need to patch
applications into using it.

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

Mmm, we can define this indeed. I'm forwarding to libc-alpha and
commiting to debian's eglibc.

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

The TCP/IP stack. Can't some feature simply be disabled to avoid having
to define all these?

Samuel


Reply to: