So I forgot to CC all the interested parties on this list (sorry about that I wasn't thinking at the time), but I did start up a conversation on linuxppc-dev on the subject of splitting out libfdt from dtc. Mainly to get the thought of what the dtc folks thought about splitting out libfdt.
The outcome of this discussion is the point of libfdt is to be integrated into different projects. I could not make a good argument at all as to why it should be split out (actually I did a terrible job at it :-)). A good analogy was made also as this is "equivalent to splitting libcrypto out of openssl". So the concessious from others in the libfdt community is the it should go in the project. This would be in line with what Hollis has been saying on the list. Now for us we can do one of the following options: 1) Integrate libfdt into our kvm-userspace or qemu (which would then require going upstream qemu folks also agree). 2) Can use wget or something to first grab the dtc source and get libfdt from it. Then place in our make file and build it. As well as point cflags & ldflags to it. (This can be done, though I wanted to avoid going this route) Here is a link to the discussion on linuxppc-dev: http://ozlabs.org/pipermail/linuxppc-dev/2008-February/052262.html On Thu, 2008-02-28 at 10:16 +0200, Avi Kivity wrote: > Hollis Blanchard wrote: > >> It doesn't have to be a package; it can be as simple as a tarball that > >> people have to make; && sudo make install before compiling kvm, the same > >> as other prerequisite libraries. > >> > > > > Sure. Let's put that tarball inside the qemu directory, and then have it > > extracted and built automatically when the user types "make". > > > > I'm really not clear on what advantage you think will be gained here. > > > > > > If the package never changes in kvm-specific ways, there is no point in > including it in kvm. The user can install it once, just like they > install the X devel packages (for example) which we don't carry in kvm > either. > > Is it indeed the case that no modifications are needed for kvm? > > >> The barrier should be whether we need to carry local changes or not. If > >> we can use upstream as is, then it should be installed independently. > >> > > > > So let me get this straight... you think it's cool to awk kernel source, > > > > Awking the kernel source is not done for the sheer pleasure of it. It is > painful to maintain and I only do it out of necessity. > > > but not to copy library code that was designed to be copied in the first > > place? Seriously? Would it be more palatable to you if I ran awk over > > arch/powerpc/boot/libdft? > > > > Including the source in kvm is of course preferable to awk, but less > preferable to an external dependency. > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel