Addition of packages: libvirt & qemu (target)
Hi guys,
First up, thanks for buildroot, its a really cool tool, and I've enjoyed using it thus far. After some discussion on IRC with y_morin, I'd like to put forward that the libvirt package is added, and that qemu is adapted to support being installed on the target as well. libvirt is a fairly standard autotools package, and shouldn't require much work, although I did notice ./configure checked for some host qemu binaries.
You can see Yann's work on libvirt and target-qemu here:
https://gitorious.org/buildroot/buildroot/source/e09cf6e8d412cfd6163358fc7f58c83f44cc0a38:package/libvirt
https://gitorious.org/buildroot/buildroot/source/14ac053363188981cf7fb78b589a9e27fb464483:package/qemu
and my inexperienced, hackjob work over here, updates the packages to their latest versions and removes unneeded depends:
https://github.com/md-5/Multiplicity/tree/master/package
libvirt requires the following depends to work:
host-pkgconf lvm2 libnl libxml2 yajl
In order for the configure script to detect yajl properly, it needs a (e)glibc toolchain. This is due to yajl requiring -lm, which is not linked into the test binary. A better solution than requiring (e)glibc would be to patch libvirt's ./configure to link in -lm for the yajl test. Yann's work on libvirt also depends on
libgcrypt and gnutls
which I assume add extra features. Ideally libvirt's depend section should be updated if these (and any other feature enhancing) packages are selected.
Building Qemu for the target on the other hand is quite a bit more complex due to the sheer number of configuration options available. In particular it depends on a x86 based toolchain with threads, and
host-pkgconf host-python libglib2 pixman
I'm reasonably sure Qemu can compile and run on other arches, however Yann has not included support for this. Ideally the final package in buildroot would only require these 4 libraries to build, additional depends and features should be added with their necessary options and installed if desired (util-linux, some sound libraries, and a lot of graphics libraries for jpg/png manipulation).
Anyway, enough of me talking, it would be great to see these two packages become properly integrated into buildroot, and I am hoping someone can manage it.
If it helps sweeten the deal, I'll be more than happy to donate some beer money to the successful contributors, or donate to the buildroot project. I'll also be more than happy to make sure these packages stay updated and working.
Thanks
Michael Dardis
Quoted 6 lines · Michael D
Hi guys,
First up, thanks for buildroot, its a really cool tool, and I've enjoyed using it thus far. After some discussion on IRC with
y_morin, I'd like to put forward that the libvirt package is added, and that qemu is adapted to support being installed on the target as well.
Just out of curiosity, what is your use case for qemu on the target?
IIRC for Yann is was just a let's-see-if-it-can-be-done hack, that's why he never pushed it anymore. I can imagine borderline buildroot uses which have lxr or docker on the target, but full-fledged qemu?
Quoted 14 lines
libvirt is a fairly
standard autotools package, and shouldn't require much work, although I did notice ./configure checked for some host qemu binaries.You can see Yann's work on libvirt and target-qemu here:
https://gitorious.org/buildroot/buildroot/source/e09cf6e8d412cfd6163358fc7f58c83f44cc0a38:package/libvirtand my inexperienced, hackjob work over here, updates the packages to their latest versions and removes unneeded depends:
https://github.com/md-5/Multiplicity/tree/master/package
Quoted 8 lines
libvirt requires the following depends to work:
host-pkgconf lvm2 libnl libxml2 yajl
In order for the configure script to detect yajl properly, it needs a (e)glibc toolchain. This is due to yajl requiring -lm, which is not linked into the test binary. A better solution than requiring (e)glibc would be to patch libvirt's ./configure to link in -lm for the yajl test.
You can typically also pass in LIBS="-lm" to configure.
Quoted 21 lines
Yann's work on libvirt also depends on
libgcrypt and gnutls
which I assume add extra features. Ideally libvirt's depend section should be updated if these (and any other feature enhancing) packages are selected.
Building Qemu for the target on the other hand is quite a bit more complex due to the sheer number of configuration options available. In particular it depends on a x86 based toolchain with threads, and
host-pkgconf host-python libglib2 pixman
I'm reasonably sure Qemu can compile and run on other arches, however Yann has not included support for this. Ideally the final package in buildroot would only require these 4 libraries to build, additional depends and features should be added with their necessary options and installed if desired (util-linux, some sound libraries, and a lot of graphics libraries for jpg/png manipulation).
Quoted 8 lines
Anyway, enough of me talking, it would be great to see these two packages become properly integrated into buildroot, and I am hoping someone can manage it.
If it helps sweeten the deal, I'll be more than happy to donate some beer money to the successful contributors, or donate to the buildroot project. I'll also be more than happy to make sure these packages stay updated and working.
We don't really have a way for accepting donations, but what we could
use is:
- more autobuilder instances;
- sponsoring for the buildroot developer meeting.
Regards,
Arnout
Quoted 10 lines
Thanks
Michael Dardis_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
Quoted 4 lines
Just out of curiosity, what is your use case for qemu on the target? IIRC for Yann is was just a let's-see-if-it-can-be-done hack, that's why he never pushed it anymore. I can imagine borderline buildroot uses which have lxr or docker on the target, but full-fledged qemu?
Couple QEMU with an x86_64 host and KVM, suddenly buildroot becomes a minimal hypervisor in a box. Now lets imagine we insert a buildroot USB / CD into a server.
The server loads the entire system into 40mb of its memory, grabs an IP and configuration parameters via dhcp, a small embedded binary reads these settings, looks at what VMs are stored on the server and starts running them. You can effectively make buildroot a quick way to spin up ultra efficient and slim hypervisors.
Quoted 1 line
You can typically also pass in LIBS="-lm" to configure.
I'll try rebuilding my toolchain with ulibc and passing -lm to configure. Hopefully that turns out well - is there a quick way to do this with an autotools .mk?
Quoted 1 line
- more autobuilder instances;
Let me know what you need for that / what it entails.
Thanks
Michael
Quoted 88 lines · Arnout Vandecappelle
Quoted 6 lines · Michael D
Hi guys,
First up, thanks for buildroot, its a really cool tool, and I've enjoyed using it thus far. After some discussion on IRC with
y_morin, I'd like to put forward that the libvirt package is added, and that qemu is adapted to support being installed on the target as well.Just out of curiosity, what is your use case for qemu on the target?
IIRC for Yann is was just a let's-see-if-it-can-be-done hack, that's why he never pushed it anymore. I can imagine borderline buildroot uses which have lxr or docker on the target, but full-fledged qemu?Quoted 14 lines
libvirt is a fairly
standard autotools package, and shouldn't require much work, although I did notice ./configure checked for some host qemu binaries.You can see Yann's work on libvirt and target-qemu here:
https://gitorious.org/buildroot/buildroot/source/e09cf6e8d412cfd6163358fc7f58c83f44cc0a38:package/libvirtand my inexperienced, hackjob work over here, updates the packages to their latest versions and removes unneeded depends:
https://github.com/md-5/Multiplicity/tree/master/packageQuoted 8 lines
libvirt requires the following depends to work:
host-pkgconf lvm2 libnl libxml2 yajl
In order for the configure script to detect yajl properly, it needs a (e)glibc toolchain. This is due to yajl requiring -lm, which is not linked into the test binary. A better solution than requiring (e)glibc would be to patch libvirt's ./configure to link in -lm for the yajl test.
You can typically also pass in LIBS="-lm" to configure.
Quoted 21 lines
Yann's work on libvirt also depends on
libgcrypt and gnutls
which I assume add extra features. Ideally libvirt's depend section should be updated if these (and any other feature enhancing) packages are selected.
Building Qemu for the target on the other hand is quite a bit more complex due to the sheer number of configuration options available. In particular it depends on a x86 based toolchain with threads, and
host-pkgconf host-python libglib2 pixman
I'm reasonably sure Qemu can compile and run on other arches, however Yann has not included support for this. Ideally the final package in buildroot would only require these 4 libraries to build, additional depends and features should be added with their necessary options and installed if desired (util-linux, some sound libraries, and a lot of graphics libraries for jpg/png manipulation).
Quoted 8 lines
Anyway, enough of me talking, it would be great to see these two packages become properly integrated into buildroot, and I am hoping someone can manage it.
If it helps sweeten the deal, I'll be more than happy to donate some beer money to the successful contributors, or donate to the buildroot project. I'll also be more than happy to make sure these packages stay updated and working.
We don't really have a way for accepting donations, but what we could
use is:- more autobuilder instances;
- sponsoring for the buildroot developer meeting.
Regards,
ArnoutQuoted 9 lines
Thanks
Michael Dardis_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Quoted 8 lines
Just out of curiosity, what is your use case for qemu on the target?
IIRC for Yann is was just a let's-see-if-it-can-be-done hack, that's why
he never pushed it anymore. I can imagine borderline buildroot uses which
have lxr or docker on the target, but full-fledged qemu?
I don't know if this is the original poster's use-case, but we have multiple customers that are asking us to help them support old ( pentium II era) software on old (win 2k) OS and the best way to do this is to use Qemu inbetween. Qemu can easily be modified to translate calls to ancient hardware into calls to modern hardware and this allows old software to run unmodified.
so a buildroot/kvm/qemu/win/legacy-software stack does make sense and we would be glad to see it supported in buildroot.
Regards
Jeremy Rosen